Parseing section one of the field file. (Field Script)-EDIT

[halkun]

When parsing a field script, how do you know how many Entity names there are? (The 8 byte clear-text names at offset 0x10) I don't see any refrence to them in the section header.

===EDIT===

This is what I have...

Section 1 Header
Offset          Size        Description
0x00---------1 byte------------Unknown
0x01---------1 byte------------Number of Sections
0x02---------1 byte------------Unknown
0x03---------2 bytes-----------Dialog Pointer
0x05---------1 byte------------Number of subroutines
0x06---------10 bytes---------Unknown
0x10---------varies------------Entity Names (ASCII text, 8 bytes each)
varies--------varies------------Section Names (ASCII text, 8 bytes each)
varies--------varies------------Subroutine Pointers (4 bytes each)

length of the header : 0x10 +(entity names+number of sections)*8+number of subroutines*4

 

[Qhimm]

Right... *digs up source code*

This is what I have (pseudo-C struct):

Code: [Select]

struct FF7SCRIPTHEADER { WORD unknown1; BYTE nEntities;   // Number of entities BYTE unknown2;   // Always less than nEntities; possibly visible entities? WORD wStringOffset;  // Offset to strings WORD nExtraOffsets;  // An optional number of extra offsets... unknown WORD unknown4[4]; char szCreator[8];  // Field creator (never shown) char szName[8];   // Field name (never shown) char szEntities[nEntities][8];   // Field entity names DWORD dwExtraOffsets[nExtraOffsets]; // Said extra offsets... unknown WORD vEntityScripts[nEntities][32];  // Entity script entry points (offsets to subroutines)};

The actual script follows immediately after the data above.

There is no distinction between entities and "sections" (in my book). All scriptable "objects" are entities, and only their scripts determine whether they are PCs, NPCs, ladders, chests or background controllers. In fact, an "entitity" is entirely defined as "a set of scripts" (entry points, subroutines, whatever the term used). The second unknown item possibly refers to the number of entities that actually display models on-screen (and thus gives the number of such controllers that need to be allocated by the script module upon loading the field), but I have yet to confirm that and as such it is just a guess at this point.

 

[halkun]

I'm guessing the visible entities are important because I think section 3 is the data for the model loader. Also, in your example, how long is a WORD? That's one of the more tricky ones that change platfrom to platfrom. (That and INT)

 

[Kislinskiy]

In Qhimm's source code you can expect the following sizes:

BYTE = 8 bit
WORD = 16 bit
DWORD = 32 bit

 

[sfx1999]

So, I guess it would be this:

Code: [Select]

struct FF7SCRIPTHEADER { unsigned short int unknown1; char nEntities;   // Number of entities unsigned short int unknown2;   // Always less than nEntities; possibly visible entities? unsigned short int wStringOffset;  // Offset to strings unsigned short int nExtraOffsets;  // An optional number of extra offsets... unknown unsigned short int unknown4[4]; char szCreator[8];  // Field creator (never shown) char szName[8];   // Field name (never shown) char szEntities[nEntities][8];   // Field entity names int dwExtraOffsets[nExtraOffsets]; // Said extra offsets... unknown unsigned short int vEntityScripts[nEntities][32];  // Entity script entry points (offsets to subroutines)};