**da Files in Battle.lgp

  • Thread starter Thread starter Alhexx
  • Start date Start date
Status
Not open for further replies.
A

Alhexx

Guest
Okay, I think I know what's written in the **da files from Battle.lgp:
I think they are simple .a files, but someone who knows the .a format properly (halkun, fice) could take a look at it.

I also think the **aa files are a kind of RSD file, **ab files sth like HRC files.

BTW: I can't see any other topics... is that my fault?

 - Alhexx
 
Alhexx... Great news about those files you discovered. I was thinking that they would be in there like that... (Wouldn't the .a files be compiled together? If not, where are the other animations?)

About the topics: Check your preferances, and change your default view to something greater than "Yesterday". I noticed this problem when I got on the board today too.

Sephiroth 3D

"I don't understand..." "You don't have to understand." - Final Fantasy: The Spirits Within

Sephiroth 3D.com
[email protected]
 
well, its much moe complicated then a normal HRC file, then. i opened up aaab in a hex editor, and couldnt even see a pattern.

edit: ok, i take that back: i see ** 01 00 00 repeated over and over.

** = some type of bone identifier in hex?

maybe this tells what parts the person/thing has.

i dont know, ive never attempted doing anything like this before.

edit2: 36 byte header + repeating ** 01 00 00 + 42 byte footer

for every different model, the repeating stuff is different, but so is what i thought was a footer. so screw that idea.


[edited] 249 2001-12-21 20:50
 
Darkness: I knwo that they're not HRC and RSD files - but I think that they have the same task. I'll take a closer look at those files later.

 - Alhexx
 
Heello, im back from my vacation, so how are you all doing ?

To the thread:
I dont think that there is any rsd file needed - there are no textures, except of eye&mouth texture, and that is allways on face.
But maybe im wrong, and there is some of this info in some unknown file.

I allways wanted to create some proggy, that would display all enemies from FF7, but im still lacking time. :(

And btw i was not working on FF for a long time, im doing something different every time i sit behind computer. :)
Dont know if i get myself to work on FF
 
Forgive me for barging in.   :D

The **aa files are the battle skeleton and tell you which bones to connect together -- it is similar to the first entry in the .lzs files in the PSX version.  battle.lgp/rvaa matches the bone structure in earith.lzs (31 bones), except that the entries are 12 bytes per bone instead of 8, and either the bone length or geometry pointer (or possibly both) is missing.  Bone numbers in the PC version appear to be one less than the PSX version, so -1 is the root locator.

The **da file is also a mystery to me, but it is identical to 73 packets in the earith.lzs file, concatenated back-to-back.  It does not appear to be either LZSS or Deflate (GZIP) compressed, as are the PSX .lzs and .x files.
 
You're forgiven ;)

And thanks for the information on the **aa files ... could be very useful when I finally get time to work on the Remake again.

Welcome to the board as well :)

Mental note: Must check out PSX files ... must check out PSX files...
 
Before you tear apart the PSX files, double check your decompressor -- the last time I tried lzs.exe I got these discrepancies in earith.lzs:

00000048: 00 70
00000144: 00 70
00000404: 00 70
0000042E: 00 70
00000DF0: 00 70
00001082: 00 70
000011B0: 00 70
00001228: 00 70
00001238: 00 70

0x70 is the correct value for these locations.

Also, the pack structure is different from the PC's .lgp files -- the directory is just a dword count of records (N), followed by N+1 pointers.  No names.
 
This could be important ;)

I've been told my LZS decompressor has bugs in it, and I've double-checked the code twice now. Never found any problems with it ... 'cept it sounds like there must be.

Do *you* have another LZS decompressor...? If so, where can I get it to compare it against mine?
 
(Ahh ... finally someone who knows what (s)he's talkin' bout -> I like that!)

(I haven't been online for 2 days, that's why I haven't posted before)

Welcome to our board, phaeron! It seems like you could (or will) be a great help for us in hacking those damn file formats...

As for my hacking progress: As you probably all have already seen, all my projects are currently freezed. My theoretical driving license exam is on 2002-03-06, so I have to concentrate on that. After that, I'll continue hacking those files, and I'll release a new Version of Ultima.
Oh, and I'll finally start learning C++ :D

(Hm ... there could be a new 'problem' in future... it seems like I'll get a girlfriend the next time ... hehe ...
love.gif
... or at least I hope so: my desired person seems to be interested in me too ... hm? Does this belong to the spam forum? I don't think so ... and I am called a moderator, heh? I think I'd better shut up now :D )

 - Alhexx

 - edit -
Had to correct some words
[edited] 169 2002-02-14 12:35
 
i started attempting to teach myself MFC, and the book is 1000 pages long!
 
My progress in learning VC++ has been going VERY slow. I've had almost no time to work on learning it. But I'm working on making a Half-life mod now, so I'm forcing myself to learn it so I can get the mod farther along with development before I need to spend time finding a real programmer to do my dirty work. ;)

Sephiroth 3D

"I don't understand..." "You don't have to understand." - Final Fantasy: The Spirits Within

Sephiroth 3D.com
[email protected]
 
I think I'm also the one you told you before.   :wink:

The LZSS compression in FF7 is identical to the LZSS compression implemented by the program at:
 http://www.rpi.edu/~ernesm/info/archive.umich.edu/mac.bin/development/source/snippets/lzcompression
except that the buffer is initialized to nulls instead of spaces.

Also,  my decompressor, with test file.  (C++ -- sorry.)  I found out that LZS.EXE is actually making only one mistake; it decompresses this file incorrectly:

04 00 00 00 01 70 EC F0 > 70 00 00 00 (should be 70 00 00 70).

Hope this helps.

The **da files are indeed the battle animations -- Cloud's bone positions begin at offset 0x20 in rtda, starting with hip.  It looks like the bone positions per frame are four bytes each, with one byte each for X, Y, and Z rotations (8-bit binary fixed-point angle), but there are some discrepancies in what modifying various bytes does.  I'm thinking that some parts of that particular animation are getting modified or overridden by other partial animations.  Also weird is that translating or rotating Cloud doesn't affect the weapon (!).
 
It was indeed you (among others ... argggh!) who pointed out the LZSS compression before ... 'cept I never *could* find an error in my code.

That sample should help a *lot*. Domo arigato! ^_^

I'll work on it when I get back in tonight....
 
Btw, when talking about compressions, anybody has some Easy example code of flate(inflate)/deflate compression ? please?
 
Compressions? Whah! Since I had to decode that 'easy' compression for Oni Textures (thanx 'gain, Fice), I don't like compression any more.

phaeron: Hey, do you have a homepage?

Okay, I'm leavin' now - my mom's buggin' me...


 - Alhexx
 
He in fact has a rather popular homepage, due to the rather popular program he's written ;)
 
Status
Not open for further replies.
Back
Top