Messages

201

FF7 Tools / Official Proud Clod 1.0 Topic

« on: 2009-11-26 04:04:54 »

What I found most interesting is that KoR SOMETIMES hit a random target, but sometimes hit both and once it didn't hit anyone! Odd. Is that part of the animation?

I don't know. It's really puzzling. If it only ever hit one, that would be understandable. I've found that even if you tweak targeting data in WallMarket, if the 'original' spell didn't support multiple targets, then the damage display and hit animation isn't shown. For instance, if you try and replace say Dragon Force with a custom attack that uses that does damage to multiple opponents, the chosen animation appears and damage is done, but the numbers only appear on one enemy. So you might expect the same to apply with a spell like shield, which, IIRC, is only single-target even with [All] attached to it. But that's not what's happening.

You need to change animation script to see damage =)
It's still calculated though.

202

Scripting and Reverse Engineering / Re: [FF7] camdat files

« on: 2009-11-25 04:20:00 »

So section 0 entries have pairs in section 1 and each camera index is a triplet (cam_ind x 3, cam_ind x 3 + 1, and cam_ind x 3 + 2)?

Yes, and win camera work the same way (exept there is only one camera).

The highest value of camera index I've seen is Adamantaimai's Light Shell. That's 0155h.
For the different battle types, these are ranges of start-cam and the camdat file they're associated with:

0,0 : 0h - 66h
1,0 : Ch
2,1 : 0h - 43h
3,2 : 0h - 2Dh
4,2 : 0h - 66h
5,2 : 0h - 2Dh
6,2 : 0
7,2 : 4C
8,0 : 56h, 58h

I'm unsure how these references translate into actual indexes. The start-cams aren't using three different cams. They're absolute. So if I'm calculating these correctly, then there are 168h "triplets" of cam indexes in camdat0.bin, 160h in camdat1.bin, and 153h in camdat2.bin.

Init camera scripts are not in camdat. They loaded with all load data earlier (they are right after init positions for players).
Init camera scripts called 3 times with the same address. So random doesn't affect it, there are same info in all slots.
Idle camera works the same way (but there is only one script for direction and one for position).

The highest value of camera index I've seen is Adamantaimai's Light Shell. That's 0155h.

0x15e - Smoke Shot for Sweeper.

203

Scripting and Reverse Engineering / Re: [FF7] camdat files

« on: 2009-11-24 14:24:42 »

There are four DWORD pointers at the beginning at 0x0, 0x4, 0x8, and 0xC

for camdat0.bin:
0x0 points to 1182 addresses in this file. Most of these are unique, but plenty are not.
0x4 has same structure as 0x0, but point to different locations.
0x8 points to 3 locations
0xC points to 3 locations (one of these is likely win cam, but what are the others?)

New info.
Offset 0x0 points to scripts for camera position vector scripts.
Offset 0x4 points to scripts for camera direction vector scripts.

There are 3 scripts for each camera id. Each of them called every time and result stored to 3 different structures. Which one to use are completly random.

 if ((game_timer & 3) != 3)
 {
  struct_id = game_timer & 3;
 }

3 is special cases, if developer want camera to work not random way.

Win camera not the exeption. there are 3 pointers to this camera.
0x8 points to position scripts for win camera.
0xc points to direction scripts for win camera.

Simple script example from start battle camera direction vector:
FA(30F8,9CFF,1027) - set start position of camera
E2(3C) - set callback function for transition from start position to idle position from battle setup with given number of steps.
F5(3C) - set wait timer
F4 - wait
FF - finish

0xE2 opcode is most important. There are few callback functions, but they fixed for opcode. calling opcode 0xE2 and 0xE8 will produce different transition effect.

Problem mostly solved =)

204

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-11-23 20:20:49 »

I upload lastest exporter to svn. Almost all models exported correctly. And there i config file where you can set what to export.
It also can be used as viewer.

205

Scripting and Reverse Engineering / Re: [FF7] camdat files

« on: 2009-11-18 17:23:44 »

There are four DWORD pointers at the beginning at 0x0, 0x4, 0x8, and 0xC

for camdat0.bin:
0x0 points to 1182 addresses in this file. Most of these are unique, but plenty are not.
0x4 has same structure as 0x0, but point to different locations.
0x8 points to 3 locations
0xC points to 3 locations (one of these is likely win cam, but what are the others?)

for camdat1.bin:
same as camdat0, but 0x0 and 0x4 point to 1125 addresses each

for camdat2.bin:
same as camdat1, but 0x0 and 0x4 point to 1122 addresses each

At a glance, I can't tell if any of the camera segments are similar to segments in other files. Why are they separated into three files? Are they different for each disc?

All this locations are camera scripts. Some of them are not in camdat though. For example idle camera script or start battle camera script.

Camdats are different for different battle layout. It's set in battle setup +0x12 byte. 0,1,8 - CAMDAT0.LZS, 2 - CAMDAT1.LZS, 3,4,5,6,7 - CAMDAT2.LZS.

206

Scripting and Reverse Engineering / Re: [FF7] camdat files

« on: 2009-11-18 14:21:45 »

I looked at those a little. There is bytecode sequence as well =)

offset 0x4 is pointer to list of offsets to camera data's (3 offsets for each camera id).
offset 0xc is pointer to 3 camera data for win camera.

At each offset start of camera sequence. Control bytes are 0xd8-0xff.

ps: still don't know why it use 3 offsets. It just call function 3 times for each of offsets.

207

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-11-17 15:24:20 »

Almost finish new field model exporter. Now it uses all the files that contain model data (BSX/BCX/TDB/DAT) ^_^
And correctly assign all textures (including eye and mouth)

208

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-10-27 12:17:49 »

You are right! This is index in normal's table. It's stored at 800df520 address (in executable, right after cos/sin table). It used to calculate final vertex color. And thgere is only 240 values (0x00-0xEF).

I've seen it in emulator memory, though it doesn't seem to be in the main executable. I just graphed it in Open Office and it looks very regular. Maybe a subdivision scheme?

I'll trace loading later. I finished with model initialization, now switch to ingame animation and model state update.

209

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-10-26 09:45:30 »

After a bit of more exploration it looks like the unused byte after each vertex colour could be the normal index. The index has similar values as the vertex index (i.e. if two vertices have the same indices, the corresponding unused values are the same as well), but the normal table doesn't seem to be in the model. Maybe it is shared across all models and stored in the executable?
Another bit: The index goes from 0 to 240 for most BCX. Only Red 13 has a few less.
It's of course possible as well that the value directly encodes the value, and is split into two angle values.

You are right! This is index in normal's table. It's stored at 800df520 address (in executable, right after cos/sin table). It used to calculate final vertex color. And thgere is only 240 values (0x00-0xEF).

210

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-10-24 19:16:06 »

2Micky: By the way did you look at KAWAI opcode? it is very much related to models and animations.

Not yet. I'll have to add texture support and some basic lighting first. I did check out the stuff from svn, though.

I understand texture completly, so look into svn. just need to fing BLINKing routine.

I update SVN daily so stay tuned. Just got to function that calculates lighting.

211

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-10-24 17:30:11 »

2Micky: By the way did you look at KAWAI opcode? it is very much related to models and animations.

212

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-10-22 19:13:35 »

I can't see if normals used at all. Data set into GPU packets directly. I continuing reversing data related to initialization of field models. Stay tuned and look into SVN =)

I think the main character is "full bright" most of the time, but I'm sure I've seen shading in some of the areas where you see the characters large. But it would explain why I can't find a normal table. I'll have to double-check tonight. I can't imagine why they would add normals and lighting information to the PC version when it didn't exist in the PSX version.
At the moment I regenerate the normals based on face normals and shared vertices.

I'll try to get my code more stable and release it. at the moment I seem to run into some special cases when decoding BSX files. (For example vertex count being 0.)

Lighting information calculated during model initialization and stored into GPU draft packets. It can be changed via KAWAI opcode which is recalculate lighting for all vertexes and store it to drafts.

Additional part in texture can be used to change global eye texture (FIELD.TDB). You can change image, palette. There is option to store given texture to anywhere in VRAM directly. And there is one more option which I can't understand. mystery solved (mostly) =)

213

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-10-22 16:03:45 »

After a bit of more exploration it looks like the unused byte after each vertex colour could be the normal index. The index has similar values as the vertex index (i.e. if two vertices have the same indices, the corresponding unused values are the same as well), but the normal table doesn't seem to be in the model. Maybe it is shared across all models and stored in the executable?
Another bit: The index goes from 0 to 240 for most BCX. Only Red 13 has a few less.
It's of course possible as well that the value directly encodes the value, and is split into two angle values.

I can't see if normals used at all. Data set into GPU packets directly. I continuing reversing data related to initialization of field models. Stay tuned and look into SVN =)

By the way did you found something about additional file in texture data in BSX?
I found it reading in asm, but cant find file where it used.

It used in in texture data if 5-7 bytes are not zeros (this is offset to something). 4th Byte are number of textures.

214

Scripting and Reverse Engineering / Re: [FF7] camdat files

« on: 2009-10-15 04:56:08 »

I don't know how they stored it on PC, but on PSX each camera frame stored as transformation packet for GTE. This is used in field to set 3d transformations for models and in movies. It must be true for battle )

215

Scripting and Reverse Engineering / Re: [FF7] camdat files

« on: 2009-10-14 19:17:15 »

This is camera packs for battle. Most likely camera data itself is stored just like in movies.

216

Scripting and Reverse Engineering / Re: FFIX code reading group?

« on: 2009-10-07 11:54:55 »

Akari may I take a look into these notes too? Also may I ask if you intend to make any .exe for running FFIX on pc?

Look at SVN of q-gears project.

There is posibiliti to make it playable on q-gears engine, but it is too much for one man to do. But noone want to help =)

217

Scripting and Reverse Engineering / Re: FFIX code reading group?

« on: 2009-10-02 20:23:00 »

I'm doing the same thing. We can join forces or you can just take all my notes from SVN.

As for now I working on scripting system. It's very interesting compare to xenogears and ffvii

218

Scripting and Reverse Engineering / Re: About savemap in FFIX

« on: 2009-10-01 16:14:57 »

Might want to talk to Chev about this thing he was working on FF9. His thread is here http://forums.qhimm.com/index.php?topic=8781.0

There is topic about models. It's better to separate things. It will be easier to find it later =)

219

Scripting and Reverse Engineering / About savemap in FFIX

« on: 2009-10-01 09:24:54 »

Did someone know where it is located in game memory. How it is organized?
I found character data, but can't find other data.

220

Scripting and Reverse Engineering / Re: [FF7, Field, PSX, Animation] BCX/BSX file formats?

« on: 2009-09-15 18:21:40 »

I added converter to SVN. Check it out.

221

FF7 Tools / Official Proud Clod 1.0 Topic

« on: 2009-08-17 21:02:23 »

This is camera movement id for attacks. 0x10 2 bytes values.

Instead of camera movement for attacks, which is stored in the attack data itself, how about camera movement for animation? I'd be willing to wager that's what that is.

There is no such thing as camera for animations.
If data in enemy is set then it will be used instead data from attack.

Code: [Select]

if (FP == -1)
{
    [address + 60] = w(hu[S4 + 8]); // set single camera from attack
    [address + 64] = w(hu[S4 + a]); // set multiple camera from attack
}
else
{
    [address + 60] = w(FP); // set camera from enemy data
    [address + 64] = w(FP); // set camera from enemy data
}
This camera data selected and used after attack calculation. Or just after action...Maybe we must call this actions instead of attacks, because not all of them harm or heal enemy. Some of them just play animations or do some other things.

It's easy to understand why it was done this way. During development all attacks was in one list or database and enemy just set id for attack they used (it was compiled into scene files lately during export procedure). Attacks define most commonly used camera movement. But some enemies require different camera, and programmers made that you can overwrite camera for specific enemy.

222

FF7 Tools / Official Proud Clod 1.0 Topic

« on: 2009-08-17 20:39:16 »

Code: [Select]

I also have a list of the unknown list of values in Enemy Data (0x68-0x87) all sorted by Enemy ID. From initial inspection, these range from 6h to 189h and only a few of the values in between are used. 113h seems to be the most popular. This list seems to be unique to Enemy ID, not Enemy and Scene IDs.

There are 46 enemies with a value other than NULL in index 0, 142 with index 1, 139 with index 2, 103 with index 3, 62 with index 4, 56 with index 5, 40 with index 6, 23 with index 7, 17 with index 8, 13 with index 9, 10 with index 10, 12 with index 11, 8 each with indexes 12, 13, 14 (ie, not the same 8, but some overlap exists), and two with index 15.
This is camera movement id for attacks. 0x10 2 bytes values.

223

FF7 Tools / Wall Market, FFVII KERNEL.BIN editor

« on: 2009-08-17 13:05:09 »

Damn. Someone flip the fields. Now it's clear. This byte used to access to high sounds id.
if bit 0x01 is on then normal sound id = normal sound id + 0x100
if bit 0x02 is on then critical sound id = critical sound id + 0x100
if bit 0x01 is on or bit 0x02 is on then miss sound id = miss sound id + 0x100

This should all be fixed in the next WM. It also seems like that third bit is important somehow, but it's always off. Used values in this byte seem to be 0, 1, and 3, but the bit 0x03 is always off.

0xF8 - 000 - none
0xF9 - 001 - normal, miss
0xFB - 011 - normal, critical, miss

There is no check for 0x04 bit so it doesn't matter. At least in battle. Maybe it checked somewhere else.

224

FF7 Tools / Wall Market, FFVII KERNEL.BIN editor

« on: 2009-08-17 07:22:29 »

He's talking about the "Model ID" label in WM. It currently contains three bytes because when I originally created the interface that's what the wiki said was the size of Model ID.
When I change the left-most byte in this three-byte value, that changes the hit/miss/critical sounds.

Damn. Someone flip the fields. Now it's clear. This byte used to access to high sounds id.
if bit 0x01 is on then normal sound id = normal sound id + 0x100
if bit 0x02 is on then critical sound id = critical sound id + 0x100
if bit 0x01 is on or bit 0x02 is on then miss sound id = miss sound id + 0x100

225

FF7 Tools / Wall Market, FFVII KERNEL.BIN editor

« on: 2009-08-17 04:03:50 »

I wasn't asking you specifically

I was just confused by the situation and asking aloud

What do you mean by sound effects? Where do you tried to change it? In weapon data there are 3 bytes that change appropriate sounds. They started during damage taking effect... i don't understand what you don't understand =)