:HEADER_BLOCK 2
:SKELETON n_sefiros_sk
:BONES 23
hip
root
1.6143456
1 BKHE
chest
hip
5.073813
1 BKIA
head
chest
4.5480328
1 BKIC
non_1
head
5.7248783
0
kami
non_1
14.583745
1 BKJB
l_chest
hip
4.7595735
0
l_collar
l_chest
2.3108385
0
l_uparm
l_collar
3.4343264
1 BKJD
l_foarm
l_uparm
4.8168325
1 BKJF
l_hand
l_foarm
2.2786036
1 BLAB
r_chest
hip
4.7595735
0
r_collar
r_chest
2.3108385
0
r_uparm
r_collar
3.4343264
1 BLAD
r_foarm
r_uparm
4.8168325
1 BLAF
r_hand
r_foarm
2.2786036
1 BLBB
l_hip
root
1.8991876
0
l_femur
l_hip
7.0923777
1 BLBD
l_tibia
l_femur
7.99837
1 BLBF
l_foot
l_tibia
6.756432
1 BLCB
r_hip
root
1.8991876
0
r_femur
r_hip
7.0923777
1 BLCD
r_tibia
r_femur
7.99837
1 BLCF
r_foot
r_tibia
6.756432
1 BLDB
What are numbers exactly for?
The SaiNt: (Please keep in mind that I am only doing guesswork.) The decimal numbers? I am guessing they are either:
1. Onscreen coordinates of the specific part of the skeleton
2. Size of the specific part of the skeleton
3. ...or something else I was too stupid to think of.
I don't know if this helps, but if you can find the corresponding .rsd files then you have the individual info for each part of the skeleton... right?
Which .hrc in char.lgp? If you can supply that info, I can poke around and tell you if I come up with anything. Is this the Sephiroth skin by any chance? (n_sefiros_sk) :wink:
I've puzzled over this before, but I'm afraid I still don't understand the .hrc structure. First it lists the header, then the... strings? Then something else that completely escapes me. The layout seems to follow an odd pattern (if pattern it is).
Headers:
1. Always have ":" in front of each line.
2. Always have the same three line format of
Line 1: The header block name (I don't understand it)
Line 2: The name of the skeleton
Line 3: The number of "bones" the skeleton has.
Strings/unknown
1. Always have four lines
2. First two lines are always a description of something (the specific part?)
3. Third line always has a decimal number (one digit whole number, decimal carried 5-7 spaces)
4. Sometimes the first two lines in the group have something at the beginning such as "1_", "r_".
5. The fourth line always has a single digit number (i.e. "0") and/or a four letter combination (i.e. "BKIA" or "0 BKIA"). The singled digit number is possibly binary as I've only seen ever seen the numbers "0" and "1" in these parts of .hrc files I've looked at.
6. Almost all of the four line strings/unknowns have a corresponding segment of another four lines further down the list. (i.e.
"hip
root
1.6143456
1 BKHE"
and
"l_hip
root
1.8991876
0")
These have the following differences:
(1) The first two lines are unaltered in cases such as "hip", and "root". Otherwise they are altered by adding something to the front of the word like "1_" or "r_". (Note that there are exceptions.)
(2) I have not bothered to check about this, but number of decimal spaces in the third line may be static. What I mean is that the number in the third line of each segment is carried to might be fixed (i.e. a segment and it's corresponding segment both have different numbers, but they have to have the same length. Example: The two seperate four line parts shown above. They are different numbers, but both have 5 decimal digits.)
Anyways, I'm stumped. Anyone know anything more about this?
Let me be the first to say I could be wrong about *any* part of this.
[This message has been edited by Srethron Askvelhtnod (edited January 04, 2001).]
head
chest
4.5480328
1 BKIC
First one (head) is name of this part. Second one (chest) is name of its "parent" part. Hip is the initial (root) part that has no parent.
The number might be a scale factor, don't know. The four letters are definitely a filename of something in the same LGP archive.
head
chest
4.5480328
1 BKIC
----------
'head' - node name
'chest' - name of parent node
'4.5480328' - distance to parent node (bone length)
'1 BKIC' - geometry file associated with this node
non_1
head
5.7248783
0
----------
'non_1' - node name
'head' - name of parent node
'5.7248783' - distance to parent node
'0' - empty geometry reference, this node has no associated geometry.
Skeletons are defined using angle/distance vectors. The bone lengths define the 'body proportions' of the model, while the node rotation info is stored in the .a files (not too hard to decode, stored as simple floats).
chest
hip
5.073813
2 BKIA BKJF
I can put two parts together!
The 2 can be changed into anything else corresponding to the amount of parts added.
One more favour,
Qhimm,since you said its possible to decode the .a files, could you help me please. I really need to turn one of the parts around about 180 degrees i think. Thanks
Qhimm: At the risk of making an even bigger fool of myself...
Now, that part I don't understand. OpenGL? What does OpenGL have to do with modifying HRC files? :-?
[This message has been edited by Srethron Askvelhtnod (edited January 05, 2001).]
EDIT: Skillster: Yes, I got your email. I should mention now that I might be away from my computer for a week or two. I'll still be able to visit the message board and check email, but I won't have access to any of my files - so no updates to my programs. Not sure yet; but I may not be able to sort anything out soon.
[This message has been edited by ficedula (edited January 05, 2001).]
@RSD940102
PLY=BKJC.PLY
MAT=BKJC.MAT
GRP=BKJC.GRP
NTEX=0
The references for the .PLY .MAT and .GRP seem to be in the .p files. I have no idea how you read the .p files so i'm stuck.
For those who want to know, in the .hrc file,
head
chest
4.5480328
1 BKIC
The no. 4.5480328
can be made a negative no.
like this -4.5480328
[This message has been edited by The SaiNt (edited January 06, 2001).]
The SaiNt: Thanks for all the info. It's a big help (believe it or not). I'm not sure, but Qhimm may have a bit of code in several of his source files for reading .a and .p files (and Lgp.h calls them Animation and Geometry).
[This message has been edited by Srethron Askvelhtnod (edited January 06, 2001).]
I have my PC again! Yay! So I *do* have access to all my files. Except I have a large technical report to write ... arg.
Ficedula: Hey, at least it wasn't two weeks.
1. What part is the "root"? Is it the legs, or does it mean that it has no parent part?
2. I haven't found any .HRC files with 2 different .RSD files referenced as in The SaiNt's example:
"2 BKIA BKJF
I can put two parts together!
The 2 can be changed into anything else corresponding to the amount of parts added."
Do any of the models ever have this by themselves? And I'm not quite sure what you mean by your last sentence. Does that mean that you can put as many parts together as you wanted, as long the total matches the number of bones listed in the Header?
[This message has been edited by Srethron Askvelhtnod (edited February 22, 2001).]
When I said
"The 2 can be changed into anything else corresponding to the amount of parts added."
I meant that you can reference one or more RSD files but you must first specify before hand how many RSD files you wish to attach to that "bone".
For example let's take the file aggb.hrc
chest
hip
4.551412
2 AGGE AGHA
Notice the number 2? This shows that two RSD files are referenced at this bone.
Basically, it means that the section "chest" is attached to the section "hip".
The number 4 here on the other hand is the distance that chest is from hip.
I not too sure what the numbers after "." represent cause I didn't see any difference after changing them.
Let's take another example of the file eyie.hrc
bone_2
root
58.32005
6 EYJB EYJD EYJF EZAB EZAD EZAF
See the number 6? This shows that 6 RSD files are referenced at this bone.
This section bone_2 is "58" units away from the root position. So, basically the numbers before the RSD references only show how many RSD files there are referenced.
Let's say I put this:-
bone_2
root
58.32005
0
bone_3
bone_2
0
1 ABCD
This would make a section called bone_2 appear "58" units away from root but since 0 RSD files are referenced, there will be nothing displayed on screen. In the 2nd section you see that a section called bone_3 is attached to bone_2 with a distance of "0" units. Now bone_3 has a reference to ABCD.RSD. This would make the object ABCD appear "58" units away from root. Get it?
You don't have to match the amount of RSD files referenced with the number of bones specified in the header. Why? Cause their both different things!!! The number of bones specified in the header only needs to be matched with the amount of bones in the HRC file. The "bones" are the the sections bone_2 and bone_3 in the example above. Theoraticaly, you could join all the RSD files in one bone but that wouldn't be the point would it? After all you don't want Cloud to be walking like a stone, right?
You won't see many files that have more than 1 RSD referenced to a single bone (especially humanoid creatures) cause it limits movement. The only reason you would want to use it is to cluster certain objects together like lets say, Aeris' ponytail and her white materia. Note that when you reference multiple RSD files from the same bone, all of them will originate from the same spot thus making it very messy unless it was meant to be like that in the first place.
As for you question on what is "root", I believe "root" is the centre of the entire 3D object since the hip is usually referenced to it. So, you should start building all your 3D objects from "root".
That's all I have to say for now. Does that answer you question Srethron?
If you need any more help feel free to ask. Do you need me to write a complete document about the HRC format?
I gotta study for my programming exam tomorrow so till then, bye!
I've already got a doc on the .HRC format, but if you know anything that you haven't shared yet, sure!
EDIT: Case Error
[This message has been edited by Clone5 (edited February 26, 2001).]
And Ficedula. How does each file determine which character it uses. Does it go by file name (axdc.hrc) or by description its desciption (avawoman)? I remember in one of the field files seeing a section that had the descriptions found in the hrc files.
My bet is on skeleton names but I don't know for sure.
The SaiNt: Hmmm, I remember saying that a few threads ago... :wink:
Clone5: Thanks. My doc isn't finished yet, either, and I've still got a ways to go.
Say, that reminds me... Does anyone have any idea what happens if you switched 2 of the .HRCs in char.lgp around?
Ficedula: I'm inclined to go for file names, but I'm not too knowledgable about these things.
[This message has been edited by Clone5 (edited February 28, 2001).]
I thought I said it before but I'll say it again. So far the battle.lgp seems to the equivalent of the char.lgp for battle characters. The .bin files like CAMDAT*.bin contain the character info like Str, Vit ,etc
What I further suspect is that the rest of the bin files will contain the prices of items and the attack of def values.
The SaiNt: Thanks for the info. You could be right about battle.lgp, however, why are there so many files? Is each battle file only a piece of the full model (like the .P files)? Where are the backgrounds and other location info kept if the battle files only have 3D model data? Also, I checked a couple battle files, and it appears that they are not compressed.
Perhaps, if the backgrounds aren't in the individual battle files, they're stored in one of the .BIN or .DAT files (scene.bin, perhaps?). Same with character info. By character info, I mean AI, abilities and attacks, perhaps a reference or two to its battle 3D model--that type of thing (not the actual 3D models). All the info for the 11 characters (the main characters + Young Cloud and Sephiroth) is in one of the .BIN or .DAT files so it doesn't have to be in each individual battle file.
Info for enemies and bosses could be in the battle files, and, if The SaiNt is right, the 3D data for *all* battle 3D models would be in the battle files. If so, I doubt that any other info besides 3D data (and maybe animations) would be in the battle files.
So where would it be? Well, we know that the game chooses which group of enemies the player will face a few steps before the actual battle. I think this could mean several things:
1. Enemy and Boss data are kept in the battle files, but only one formation per file. To illustrate my thinking, let's take the first scene of FF7. At first you can't encounter enemies there, but once you've fought the two MPs, and left to the next scene, if you go back the random battles will be (IIRC): (1) 2 MPs, (2) Guard Hound, (3) Guard Hound and MP. Now, suppose that the game has one battle file for the 2 MPs, another for the Guard Hound, and another for the Guard Hound and MP. If this is true, the game just randomly chooses from an appropriate group of battle files to decide who you fight next.
2. If #1 isn't true, then all of the enemy info for an area might be kept in a single battle file, all the data for various enemies, formations, and backgrounds. Each battle file would have a list of all the enemies found in it (with all of them starting out labeled as "inactive" via a flag or switch).
This would mean that when the game decides which formation you'll encounter in the next battle, it sets a switch or a flag inside the battle file that "activates" the appropriate enemies (or, it just removes their inactive status). The battle file's list of enemies is then reset after the battle is over.
3. If #s 1 and 2 aren't true, Enemy and Boss data might all be kept in one of the .DAT or .BIN files. That would mean that the battle files just know which enemies (and how many) to load (flags/switches again).
4. Same theory as #3, except it's not the battle files that load the enemies. Instead, the game engine does it.
I don't know much about the .DAT format, but audio.dat is like an archive that contains all of the sounds, so it wouldn't surprise me if they did something similar for enemy data.
We have 5 .DAT files to choose from:
enemy012.dat
enemy331.dat
kage.dat
mark.dat
Stage57.dat
Most of these files are pretty small. The two smallest (mark and kage) are LZS compressed, but still itsy-bitsy when decompressed.
My first thought about enemy012 and enemy331 was that they were the Emerald and Ruby WEAPONS. I thought this because I knew they'd been added to American and European versions of the game, so the programmers probably just tacked on the data for the two enemies without bothering to put them with the rest of the enemy data. There are a couple problems with this, though. First, one is more than 20 times bigger than the other--I'd expect their size to be similar. Secondly, it would probably have been just as easy for the programmers to put the data of Emerald and Ruby with the rest of the monster/boss info. After thinking it over, I've discarded this idea in favor of another.
I think enemy012 has all (or most) of the info for the bosses, and enemy331 has all the normal enemy info. Why? Well, first, the numbers (012 and 331) got me thinking. I know there's more than 12 boss fights, but for some (i.e. the Turks, Jenova) you fight them multiple times throughout FF7. The only things that change are their stats/abilities/AI. As far as 331, that sounds about right for the number of enemies in FF7. Doing some quick math, the Official Strategy Guide lists 264 enemies (including bosses) in it's bestiary, and it is missing a number of enemies, including ones found only in the battle arena, various other enemies that it forgot, and Ruby and Emerald WEAPONS (and possibly Ultima, too) who might not be considered Bosses by the game (normal battle music plays when you fight them).
If this hunch of mine is correct, it means that enemy012 holds data for 12 enemies (probably bosses) and enemy331 holds data for 331 enemies (the rest). Another possibility is that the two files hold the formations, not individual data. There are probably 331+ different formations throughout the game.
What about mark and kage? Perhaps my original way of thinking about Emerald and Ruby *could* be right, and it's actually these two files instead. They *are* both small and roughly the same size.
Stage57.dat could be the backgrounds. Like all the rest, just a guess.
What do you guys think? Perhaps The SaiNt knows something more about this from his .EXE research? I really am not sure about this, but I thought I'd share where my analysis has taken me. Hey, hopefully it's enough to at least get you guys thinking. :wink:
[This message has been edited by Srethron Askvelhtnod (edited March 03, 2001).]
The Skillster: Are you saying that the entire game is split up into 57 different stages, or just the battles, or what?
The Skillster: I suppose it's possible. Something like that would likely have a great deal to do with the .exe.