FF7PC Field File stuff.

[halkun]

I noticed, that's really cool. I don't reconize the bottom location, what odd is there are walkable areas that are outside the normal paths.

Dumb request, but could someone post a picture of costa del sol or some other *really* identifiable area. Just for giggles ^_^

 

[Aaron]

I think the bottom location is the floor of the Shinra building where you get thrown into a cell, and wake up to find a trail of blood.

Anyway, this is pretty impressive, yeah.

 

[Kero]

More accurate version of section 3 is in my post from 2005-02-01 10:52 . Well, this post has bad interpretation of lights, but read it too (some ideas ect are here)

First of all, there is nothing like i dont know anything about decoding, I dont know anything about that, its just I programmed few things like that so I have an idea what shoud be there and what not. You have section and change values, put it back to lgp files, run. Observe reults. Again, again, again... forever. Thats all.

second> some parts of text I post here are rather incomplete or there are slight mistakes. Dont let it bother you, just open some filed file, find section and look at what i wrote and follow. For example if there should be x coordinate it probably wont be -25478. Also, my results are based only on few files (2-3) and after I will have time, I will make some checker and run it on all files, so if there will be irregularity, I can find it (like, there is only one file, where camera section is 114 bytesl long, and it arent three same cameras).

Does anyone know anythink about  section 6? I think that it is just trash. Pure trash and few checks about if file is really from original field file. Well I looked only on first section
Code: [Select]

S32 offs1;S32 offs2; S32 offs3;S32 offsEOF; // offset to the end of file now comes data from section one, it seems like slight fibonachi sequence with few irregularites.

Example what I found in condor1 file
-120  0 20  | -104 20 20 | -88 40 20 | -72 60 20 | -56 80 20| -40 100 20| -24 120 20| -8 140 20 | 8 160 20| 24 180 16| 40 196 13  | 56 209 12| 72 221 12| 88 233 11| 104 244 11| 0xFE7F 0 0| 24 255 4| 40 259 4| 56 263 4| 72 11 4 (*)| 88 271 4 | 104 275 4 |0xFE7F 1 0 | 0xFE7F 24 279  5  40 (**) |284 6 56| 290 6 72| .....blah blah blah. It will end with 3x 0xFE7F.
As you can see It is divided into triplets first number in triplet is always previous first number in triplet + 16, other two numbers in triplet are just some modification of fibonacchi sequence > second number in triplet is addition of second number in previous triplet and third number in previous triplet. Of course, there are some irregularities and I didnt pay attention to rest of parts of section  6  more than few second, but I dont think that there are valueable data. If someone can proof me wrong, I would be glad. I just thing that it is similar with checksum in .p files ( second half of .p files are too some sort of sequence, but I hadnt crack it yet)

Not to valuuable data.

Section 3
 well, it is obvious that there are informatuions about objects in scene (indexed, so scripts can easily points on them). It doesnt seem that anyone paid attention to it more, so it decoded it. More or less... more than less.
Code: [Select]

typedef struct {  S16   blank; // is it always zero?  S16   numchar; // number of characters  S16   offs004;  object charinfo[numchar];} sec3;

struct  sec3 is complete section 3. If you see array like object charinfo[numchar] - it just says that it is arraywith 'numchar' items (it is defined structure).  Hope more or less clear.  First is blank number = 0x0000, after that is number of objects in this section (i use character, since it is mostly some character, but it can be also crate, savepoint ect). Some unknown number.  after this follows numchars objects. objects are defined with following structure.

Code: [Select]

typedef struct {  S16   charnamelen;  chars charname[charnamelen];  S16   blank;     // 0 end of string?  char  skeletname[4];  // AAAA  U8    separator1; // 2E  char  skelet_suffix[] // "HRC512\0" sometimes "HRC1024\0"  U16   numani;        // number of animation or whatever it is. see ani[]  S16    unknown1[6];  // [1] some coeficient for diffusion of light  vector3S16 source;   // vector for light position, size is 4096  S16    unknown[6];    // firs few are probably coefficients                        //  [x] --- unknown[x]                        // [0] blue                        // [1] ,[2],[3] dont know anything                        //                        //                        // [4] red                        // [5] green  animation ani[numani];} object;

first there is lenght of name for object, after that is charnamelen chars ,without ending \0 , instead of it there is S16 blank number (seems to be always zero). after that is name of skeleton (probably hardcoded to lenght 4), separator of strings (0x2E),  after this is string ending with 0 (in C manner) of with unknown meaning to me (why is there sometimes HRC512 and sometimes HRC1024 or maybe even other names).  After this is number of animation this object can use in this field file.
Now is here light. Well,  I have some idea what is going on there, but details are sill unknown. It seems that there are two parts of light
  1] spotlight  - it has source
  2]ambient light - even if there is not any lightsource, object will still be litted from every side.  
properties of spotlight are stored in unknown1 -- shiness, how does intensity of light decrease according to angle (NOT DISTANCE - there is nly vector - direction from where light comes, but is is more silmilar to sun, than to flashlamp).  after that is vector where dioes light comes from and properties for ambient light.  first is blue, the bigger this is the more blue is ambient light.. after this three S16 with unknown meaning to me (it I changed these, i didnt observe any difference).  Then red and green - same properites as blue. blue, red and green are often pretty big 19000 and such.
numAni animation follows.

Code: [Select]

typedef struct {  S16 lenght;  // how long will be anme of next animation  char name[lenght];  // ACFE.aki | ADCC.tor | ????.yos // . == 2E  S16 unknown; // often 0x0001 - maybe end of string?} animation

A you can see, nothing difficult. first lenght of name of animation file, after this name of animation file (0x2E is separator of name from suffix) without zero at the end, then unknown number , often  1 and it s all.

 

[Kero]

More accurate version of section 8 is in my post from 2005-02-02 00:29   . Well, this is just previous version.

gatways - thats how I call areas on which you step and you are transffered to another location.

Code: [Select]

typedef struct {  S16 x;  S16 z;  S16 y;}vector3S16typedef struct {  S16 left;  S16 bottom; // maybe top, I dont know/care Its nearly always centred  S16 right;  S16 top;    // maybe bottom.} range;

Gateways are stored in section 8 of field files. Section 8 is always 740 bytes long, maximum of gatways for one location is 12. Stucture of section>
  *  header
  *  gateways
  *  unknown part 1
  *  unknown part 2
  *  triangles

header
======

typedef {
    char name_of-location[8];
    U32  movement;
    range  picture;
    U32  blank;
    range range1;
    U32   blank1[6];
} sec8header`

movement - what direction will character go if you push up, down,left,m right. 128 (0x80) is key-direction (up-up, right-right, down-down, left-left), for 64 (up-right,right-down,down-left,left-up), 32 (up-leftup,right-leftdown,down-rightdown,left-topright)....i dont know how these directions are called.

range picture - you have noticed that your character stays in the center of screen, unless you are near of borders of picture(if you are there, character wont be in the middle, but can move to the very border of image ... well if you define range of picture smaller than is walkmesh, you character can walk out of screen and you wont see it at all). This is what define these borders.  Values are in pixels, range if defined from the center of background image (bg image is 300*200 and you define left = - 145, right = 145, top = 98, bottom = -98).

range 1 - well, I dont know if it really is range, just unknown values, probably not, but better than writing four unknown values, every is 1024.
blank,blank1 - seem to be zero, have to run statistical test.

Thats all about header.


gateways
========
gateways starts on offset 0x38 from the start of section.
struct {
  vector3S16   corner1;
  vector3S16   corner1;
  vector3S16   pos;    // place where char will apear after transfer.
  S16 destindex; // index in maplist
  U32 unknownl;  // 0x84848484 ot zero ?
}gateways;

corner 1 and corner2 defines two corner of 3D area in which if you go, you will trigger the gateway and will be transferred do destination. pos is position in destination (x,y,z) where you will appear. Just look at walkmesh value and choose some number so you are ON walkmesh and not BELOW. also you have to snad on some polygon of walkmesh (obviously).
destindex is index destination. Every location has its index defined in maplist (or something like that). In maplist are first 64 +-1  destinations on worldmap. If you swap two destinations in maplist, nothing happens, it is probably only for referrence and doesnt actually determine index of location. As every part of sectio 8 gateways have 12  structures gateway. If destination is 7FFF {maximum positive number for S16} then gateway is not active.


unknown part1 & unknown part2
=====================
this is weird, these are just default values.  I have to find section 8 where these are not default and all the same.

triangles
=======
this part determines where the red triangles showing where is gateway in the game appear on the screen. I dont know much more then that.

 

[ficedula]

4. I would be very  pleased if someone (ficedula) modified lgptools so I could on command line exectute lgptools.exe replace 125 ancnt4.dat  and this would do the same as run lgptools, open lgp archive. click on file with index 125. click on replace. find file i want to replace it with, ok. I cant find source and writing it from scratch seems compleatly useless if working program is here.

This was already done ... years ago ... except for some reason it's missing off my webpage :/  Must have been lost over the (many) host moves.

http://www.ficedula.co.uk/lgp.exe

...although be warned, I've not even looked at this code in years, so for all I know it might destroy your data and murder your close relatives.

 

[Kero]

Thanks ficedula.

Here comes more accurate decription of section 3
Field file - section 3
======================

This section is about data for showing 3d objects actually to screen, to do that you need some external data and names of files for these data is what is stored here.
Note to position: I am changing sign or something like that so, if you will take x,y,z and change signs according to me, you will get correct position in walkmesh. I just load walkmesh. coordinates [x,y,z] in walkmesh are just x,y,z. No change.

Code: [Select]

typedef struct {  S16   blank; //  always zero  S16   numchar; // number of characters  S16   size;    // same as size  object charinfo[numchar];} sec3;

Lets dig in. Sec3 is structure for complete file.
blank - always zero.
numchar - number of 3dobjects in field. Although it is named char(acters), it can be anything, savepoint, treasure box...
size -- everywhere I lookes was same as size after .HRC (look below for more info), but nothing happend if I changed it(PC version). I thought it is maybe backup if size is not define after HRC then use this. Again wrong. Well, I dont know what it is for, just give it same size as you give after ????.HRC. It doesnt resize walkmesh either. Maybe obsolete from development when they thought it would be nice to have one resize for all and after that they thought it would be nice to let every object have different resize.

Code: [Select]

  typedef struct {  S16   charnamelen;  chars charname[charnamelen];  S16   blank;     // 0 end of string?  char  skeletname[12];  // AAAA.HRC1024 or AAA.HRC512\0 - just 12 chars, no ending zero  U16   numani;        // number of animation or whatever it is. see ani[]  light_s light[3];    U8      ambientred;  U8      ambientgreen;  U8      ambientblue;    animation ani[numani];} object;

After few necessary information comes numchar * structure object. It has all information for 3dobject - name of skeletonfile, animations and such.
charnamelen - lenght of name for this object. Not really sure, whether there are some rules, but every name I have seen was something like [name_of_location_file][description_of_object_or_its_name][separator, is always 0x2E]char -> eg. condor1main_n_cloud\0x2Echar .charname is string without ending zero, only characters of string.
blank - seems to be always zero
skeletname - every skeleton file for field is 4 chars long (eg. AAER). Then there is separator 0x2E, chars HRC and after this is number of maximum four digits (often 512 or 1024 ). This number define resize value. Every skeleton has some lenght of bones, its .p files have vertexes with some coordinates for x,y,z. These coordinates and lenghts are to be multiplied by this number. TO sum it up, this number define how bigger object will be than is in original files (I hope, I maybe there is some sort of fixed point, but bigger this number is, bigger object on screen). (look ar http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor1_hrc768.png and compare with http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor1_hrc1024.png)
numani - number of animation for this object

Code: [Select]

typedef struct {  U8         red;         // composition of light for spotlight  U8         green;  U8         blue;  vector3S16 pos;         // position. I walkmesh [-x,-y,z] } light_s;

light[3] - every object has three light sources, you can choose its position (distance from [0,0,0]: square often use something around 4103+-5, I have seen 2095... just use imagination) and intensity of each component of light. The bigger is vale for some component the more it will take effect (you can use red for bloodfiled ^__^). Position has to be adjusted.
Code: [Select]

  pos.x = -x;  pos.y = -y;  pos.z = z;

after lights with source, there is ambient light (light that is everywhere, no shading), again, you can define intensity of each component. Picture will show how does ambient light look, so I dont have to explain.

Code: [Select]

typedef struct {  S16 lenght;  // how long will be anme of next animation  char name[lenght];  // ACFE.aki | ADCC.tor | ????.yos // . == 2E  S16 unknown; // often 0x0001 - maybe end of string?} animation

And last part of are animation. There is numani * structure animation.
lenght - lineght indicator for animation
name - string without zero at the end. [name_of_animation_file][separator 0x2E][aki^yos^anm] like GWIE.anm, HOJD.yos, AAGA.aki ...What is meaning in different suffixes I dont know.
unknown - seems to be always 0x0001

Created by Kero ([email protected])
If you find error, PM me or mail me.
I spent some time researching and writing this (10hrs, light were nasty), so if you find this usefull and write program be so kind let me know.
Thx goes to ficedula, halkun, alhexx..

EDIT:
TODO
sec3.blank - always zero.
sec3.object[].blank - zero or 1.  Nothing changed even if I set it to 0x11. Dont know purpose.
sec3.object[].ani[].unknown - various values from 0 to +-200

Link to simple convertor from sec3 to human readable format and it's source
You may need to use section divider (src).

 

[Kero]

Field file - section 8
========================

Gatways - thats how I call areas on which you step and you are transffered to another location.
Every every offset is here relative, 00 is at the start of section 8 (after lenght indicator).
Gateways and related data are stored in section 8 of field files. Section 8 is always 740 bytes long, maximum of gatways for one location is 12.
Stucture of section>
 * header
 * gateways
 * triggers
 * singles
 * triangles

 

Code: [Select]

typedef struct {  S16 x;  S16 z;  S16 y;} vector3S16;typedef struct {  S16 left;  S16 bottom; // maybe top, I dont know/care Its nearly always centred  S16 right;  S16 top;    // maybe bottom.} range;

header
======

Code: [Select]

typedef {  char name_of-location[8];  U32 movement;  range picture;  U32 blank;  range range1;  U32 blank1[6];} sec8header`

movement - what direction will character go if you push up, down,left,m right. 128 (0x80) is key-direction (up-up, right-right, down-down, left-left), for 64 (up-right,right-down,down-left,left-up), 32 (up-leftup,right-leftdown,down-rightdown,left-topright)....i dont know how these directions are called.

range picture - you have noticed that your character stays in the center of screen, unless you are near of borders of picture(if you are there, character wont be in the middle, but can move to the very border of image ... well if you define range of picture smaller than is walkmesh, you character can walk out of screen and you wont see it at all). This is what define these borders. Values are in pixels, range if defined from the center of background image (bg image is 300*200 and you define left = - 145, right = 145, top = 98, bottom = -98).

range 1 - well, I dont know if it really is range, just unknown values, probably not, but better than writing four unknown values, every is 1024.
blank,blank1 - seem to be zero, have to run statistical test.

Thats all about header.


Gateways
========
 gateways starts on offset 0x38 from the start of section.

Code: [Select]

struct {  vector3S16 corner1;  vector3S16 corner1;  vector3S16 pos; // place where char will apear after transfer.  S16 destindex; // index in maplist  U32 unknownl; // 0x84848484 ot zero ?}gateways;

corner 1 and corner2 defines two corner of 3D area in which if you go, you will trigger the gateway and will be transferred do destination. pos is position in destination (x,y,z) where you will appear. Just look at walkmesh value and choose some number so you are ON walkmesh and not BELOW. also you have to snad on some polygon of walkmesh (obviously).
destindex is index destination. Every location has its index defined in maplist (or something like that). In maplist are first 64 +-1 destinations on worldmap. If you swap two destinations in maplist, nothing happens, it is probably only for referrence and doesnt actually determine index of location. As every part of sectio 8 has 12 structures. If destination is 7FFF {maximum positive number for S16} then gateway is not active.


Triggers
===================
from offset 0x158 till 0x218 - size of 1 item is 16

Code: [Select]

struct {  vector3S16 corner1 ; // 6  vector3S16 corner2 ; // 6 12  U8 enterstate;   // I have more or less faith into defaultstate, but not these two  U8 leavestate;   // names are probably wrong  U8 defaultstate; //   U8 sound; // index zvuku, ale v jake databazi? } triggers

if you step in/out area between corner1 and corner2, you will
 * hear sound with id sound (dont know where is table for indexes)
 * there will be chage in background (mostly used for opening/closing doors)
 
  enterstate - what sprite show if you enter into area
  leavestate - what sprite show if you leave area
  defaultstate - what sprite show at the start
   These three values are somehow connected to background, at first I thought they define what part of script shoud be called if stepper into/out, but it doesnt seems so (nearly sure, I changed script and changes of background stayed). Still not toos sure about WHAT they are indexing. Have to research section 9 properly.

Singles
======
from offset 0x218 till 0x224
one byte for one item. Dont know what these are for. Values 1 or 0


triangles
==========
from 0x224, lenght of setion 192 -> 16 bytes per item.
This part determines where the red triangles showing where is gateway in the game appear on the screen.

Code: [Select]

struct {  S32 pos.x;  S32 pos.z;  S32 pos.y;  S32  visible; // is it visible? 01 true 00 false} triangles;

pos - position in walkmap. No sign changes necessary.
visible -  0 - trinagle is not visible
           1 - triangle is red
           2 - trinagle is green
          >2 - trinagle is red
        - I am not really sure if all bytes from U32 are used only for visibility - >run statistical correction

TODO:
triggers[].*state
triangles[].unknown
rest of header
statistical correction for visible
spelling&grammar check

Now we can sum it all.
Field  files - we know how sections are defined.

Every section stores specifical data.
section   purpose
1         Dialogs and game scripts
2         Camera,its direction and position, FieldOfView
3         Names of files for loading 3d models - meshes, skeletons, animations  
4         Palette
5         walkmesh
6         Junk data
7         random enemies
8         Gateways
9         Background images and sprites

Section 1 scripts ect. are not decoded enough, I dont think we can make our own.
Section 2 - meaning of values decoded from 90%, interpretation from 70%. atribut size somehow define viewvolume, unfortuantelly not enough for practical use.
Section 3 -  enough for practical use. 95%
Section 4 pallete - compleatly decoded
Section 5 walkmesh - decoded.
Section 6 - trash, just copy from another field file

I checked section 6 and it really is pure trash. More correctly, I replaced 25 000 bytes long section 6 in wutai with 2 500 bytes long from condor1 and hadnt see any difference in behaviour of filed. Maybe I just didnt pay enough attention, but for now, lets call it junk, trash....

Section 7 random enemies - I have seen it decoded somwhere, but dont know where
Section 8 enought for practical use.
Section 9 - havent looked enought into this, but I dont think document ficedula&qhimm  wrote is enough (I would like to see sources of 7mimic),

I think I did good job in decoding. But still not enough for good field file editor.

 

[Cyberman]

Interesting stuff, the fact they used ambient lighting interests me.  Perhaps they planed on using this to make the person look like they are in a light or dark place. In other words in shadow or outdoor light, or maybe that was there intention and they never got around to it as well. (Yet another than to add to the engine (Check ambient lighting for ambient lighting affects ).

The walk meshes seem a bit large for just one field location.  Are they for a single or multiple field locations?  There must be 'gateways' located within the mesh's bounds.  What is the purpose of red versus green triangles. I don't recall that in the game.

This is of course for the PC version of the game (section 1 - 9 are different on the PSX). However it is very good you provide this information I can examine the PSX data and compare results
I just started ploinking on my viewer and have been improving it's basic functionality bit by bit.  I'll post some fun things I have been informed of in another thread (FF8 related).

I suppose my next task is finding the walk mesh in the PSX data.  It appears that section 9 is located in the ????????.MIM files and the remaining sections are located in the ????????.DAT files. Do you know where the field models are kept in the game? Maybe section 6 is a redundant copy of the PSX field model information (????????.BSX files)? Just a possibility you might not have considered.


Cyb

 

[Kero]

Interesting stuff, the fact they used ambient lighting interests me.  Perhaps they planed on using this to make the person look like they are in a light or dark place. In other words in shadow or outdoor light, or maybe that was there intention and they never got around to it as well. (Yet another than to add to the engine (Check ambient lighting for ambient lighting affects ).

I dont think so, ambient lightning is normally replacement for radiosity, but it takes much less time(and results are of course far from real, but sufficient), and is used (ambient light) in most games I have seen.  OpenGl model for light:

Emitted, Ambient, Diffuse, and Specular Light
Emitted light is the simplest - it originates from an object and is unaffected by any light sources.

The ambient component is the light from that source that's been scattered so much by the environment that its direction is impossible to determine - it seems to come from all directions. Backlighting in a room has a large ambient component, since most of the light that reaches your eye has bounced off many surfaces first. A spotlight outdoors has a tiny ambient component; most of the light travels in the same direction, and since you're outdoors, very little of the light reaches your eye after bouncing off other objects. When ambient light strikes a surface, it's scattered equally in all directions.

Diffuse light comes from one direction, so it's brighter if it comes squarely down on a surface than if it barely glances off the surface. Once it hits a surface, however, it's scattered equally in all directions, so it appears equally bright, no matter where the eye is located. Any light coming from a particular position or direction probably has a diffuse component.

Finally, specular light comes from a particular direction, and it tends to bounce off the surface in a preferred direction. A well-collimated laser beam bouncing off a high-quality mirror produces almost 100 percent specular reflection. Shiny metal or plastic has a high specular component, and chalk or carpet has almost none. You can think of specularity as shininess.

Although a light source delivers a single distribution of frequencies, the ambient, diffuse, and specular components might be different. For example, if you have a white light in a room with red walls, the scattered light tends to be red, although the light directly striking objects is white. OpenGL allows you to set the red, green, and blue values for each component of light independently.

The walk meshes seem a bit large for just one field location.  Are they for a single or multiple field locations?  There must be 'gateways' located within the mesh's bounds.  What is the purpose of red versus green triangles. I don't recall that in the game.

I dont recall red x  green either, its just color. I dont understand what do you mean by "walk meshes seem a bit large"? One walkmesh is for one field file (although some locations use same walkmesh, but every field file has its own). You just see part of location and move on it. Character stays in the center of screen (excpet : see header of  section 8: range picture).  Walkmesh is defined through vertexes and triangles. Each gateway is defined through two coreners of block.  These corners are defined in walkmesh. If walkmesh is onw triangle (x,y,z, left handed coordinates) [0,0,100],[-100,0,-50],[100,0,50] and you define corner one and two as [-10,0,10]x[10,10,-10] then if you step in the middle of triangle you will be transffered into different location.

I suppose my next task is finding the walk mesh in the PSX data.  It appears that section 9 is located in the ????????.MIM files and the remaining sections are located in the ????????.DAT files. Do you know where the field models are kept in the game? Maybe section 6 is a redundant copy of the PSX field model information (????????.BSX files)? Just a possibility you might not have considered.

I have never seen FF7 in PSX version, so I cant help at all.
In PC version field characters are stored in  /data/field/char.lgp. You can view them in ilfana.

 

[Cyberman]

I dont think so, ambient lightning is normally replacement for radiosity, but it takes much less time(and results are of course far from real, but sufficient), and is used (ambient light) in most games I have seen.  OpenGl model for light:

Hmmm I'm not sure they used lighting for any of the battle models.  I also don't  recall if the characters lighting changes at anytime during the game.

Lighting information removed I know quite a bit about lighting types and differences in them etc.  Phong (specular diffuse) Tarus Sparrow models (similiar to Phong only closer to reality) etc etc. I did a few papers on it over 15 years ago  I still even dabble in it but I don't have as much time as I use to.  Anyhow what I was really asking is there more than one ambient light definition and if so is it based on the triangles in the walk mesh.  I doubt they have any real light sources, though it is possible to do that on the PSX hardware (just slow).  

I dont recall red x  green either, its just color. I dont understand what do you mean by "walk meshes seem a bit large"? One walkmesh is for one field file (although some locations use same walkmesh, but every field file has its own). You just see part of location and move on it. Character stays in the center of screen (excpet : see header of  section 8: range picture).  Walkmesh is defined through vertexes and triangles. Each gateway is defined through two coreners of block.  These corners are defined in walkmesh. If walkmesh is onw triangle (x,y,z, left handed coordinates) [0,0,100],[-100,0,-50],[100,0,50] and you define corner one and two as [-10,0,10]x[10,10,-10] then if you step in the middle of triangle you will be transffered into different location.

So basically each field file stores the entire walk mesh for the area it's in with new exits and and camera information for each.  That makes sense.

I have never seen FF7 in PSX version, so I cant help at all.
In PC version field characters are stored in  /data/field/char.lgp. You can view them in ilfana.

Are those just the character models? (They are stored as <NAME>.BCX on the PS1 version.)  Do you know if that includes the different field models for each field location? Each fiel d location has a unique set of field models that appear at that location. Such as wutai and midguard.  Characters are stored seperately.   Combat dialogs such as the ProudClod scene are just that combat models and are not in Field models.  It means for example in the Shinra building top floor there are President Shinra Rufus and any other model of a NonPlayer Character stored in it that is at that field location.
I believe Micky posted the information reguarding the field models etc.

In any case it's not a big deal.

Cyb

 

[halkun]

I think I did good job in decoding. But still not enough for good field file editor.

It's not so much an editor that would be cool, but a "player" would be kind of nice. That's where I think efforts should be aimed towards.

 

[L. Spiro]

It is all good and useful as well.
I will need it for my engine, but you go too fast.

I haven’t started programming this into my engine yet, because, to be honest, at times your notes are very confusing.

In the beginning I simply could not follow your notes, but I know that since then you have rewritten things, and if I take the time to read this entire post I can probably put it all together.

Whenever you’re done with this, figure out the battle animation format.

I will look over this all in more detail when I am ready for this addition to my engine, but for now it seems to be nice work that (seemingly) no one else here could do.


L. Spiro

 

[Kero]

It is all good and useful as well.
I will need it for my engine, but you go too fast.

Dont worry, there is nothing wrong with it. I did walkmesh 3 months ago and then was long pause and I did something again.

I haven’t started programming this into my engine yet, because, to be honest, at times your notes are very confusing.

I guess (especially the one from 2004-09-27 13:35 ).  Mostly I add a lot of new information and post new reply while old one if still there.

Well, the worst is field scripting, without it this cant do nearly anything. Field scripts are the core, but PSX version is far more suitable for that. Oh well.

Anyhow what I was really asking is there more than one ambient light definition and if so is it based on the triangles in the walk mesh. I doubt they have any real light sources, though it is possible to do that on the PSX hardware (just slow).

Every character is rendered with three spotlights (probably just descover intensity in corners of triangles and then gourard (phong is too difficult for PSX I think)) and ambient light. Every character  have definition for these lights, although it is same for character in file I have seen,  I can be defined per case. They are not based on triangles (or at least I dont know)

 

[ruby54501]

I was told by Eidos Support that this is why the company stop support for FF7 six years ago cause they could'nt fix the crash! Did some one else? I have use all the downloads no go! Or can I just skip this!