Author Topic: Bingo! (Read 16189 times)

The SaiNt · « **on:** 2001-07-02 19:30:00 »

Ok, I looked at some of the field files today and it appears that "Section 2" keeps the data for the walkable / non-walkable coordinates.

Section 2 seems to be constantly 42 bytes in size.
It also always begins with the same 4 bytes:-

26 00 00 00

and ends with the last byte as 01(All values in hex).

I haven't looked at everything in this section in detail yet but anyone care to continue this for me? I don't exactly have the time to compare every file one by one to find the pattern.

I'm not sure if the above-mentioned stuff applies to all files, but it applied to all the files I've opened so far.

BTW, fice do you know where the data for which MIDI file to load is in the field file?

And you didn't add the sections on where to find the text kept in the field files?

ficedula · « **Reply #1 on:** 2001-07-02 19:43:00 »

Um, how can you store all that data in 42 bytes??? 38 once you take away the length indicator?

Text and midi indicator data is stored at the end of the first section. I didn't include it since I don't fully understand it. Really, I don't know much more than 'go to end of section, look for data that could be text-like...'.

The SaiNt · « **Reply #2 on:** 2001-07-02 20:35:00 »

Basically, I was pretty surprised too to find that it was this section that affected the walkable / non walkable sections.

If you don't believe me, go ahead and replace this section from one field file to another, you'll get what I mean.

Could it be that it only stores the co-ordinates of a 19 point shape?

Honestly I could be wrong since I have not tested this throughly yet. From what I tested, it completely changed the walkable sections, or maybe it shifted the walkable layer. If this proves to be the walkable / non-walkable section, then there's one more thing you should know. You can't seem to place 3D objects where the area is non-walkable. Shopkeepers (3D objects) and such get "moved" out of their original positions and they are repositioned to walkable areas.

I'll continue working on it if no one comes up with anything new by the time I'm free again. Maybe tommorow. Time to sleep

fice : BTW, I'm wasting a hell lot of time cause FFLZS100 doesn't accept wildcards

[This message has been edited by The SaiNt (edited July 03, 2001).]

CT-CyberTech · « **Reply #3 on:** 2001-07-03 10:18:00 »

Now Honestly I have no say in this seeing as I don't have a PC copy of the game you are talking about(I don't think so at least heh), but maybe the data is encoded/compressed, that would explain its small size. And as for the moving objects, the games 3D engine probably is as you said programmed not to allow objects to be placed in those areas, _OR_ maybe the coordinates after being decoded out of the 38 bytes(if thats needed) have it so:
   00 00
    | ^---> Walkable coordinate
   Object Coordinate
and thats how it may go thoughout the whole file after being _possibly_ decoded.

CT-CyberTech · « **Reply #4 on:** 2001-07-03 10:20:00 »

Dang it, it took out my tabs, I meant that maybe it goes as 1 hex value for the object, then the following for the walkable area, or visa-versa, in 2 Byte intervals for the whole thing.

The SaiNt · « **Reply #5 on:** 2001-07-03 19:46:00 »

It really looks like section 2 was only for shifting the positioning of the walkable map.

I am able to "change" the walkable map by moving it around. The exits also seem to move together with the "walkable" terrain. The 3D objects also seem to move together with the terrain.

Thus, I think it would be right to conclude that this is not in fact the "walkable / non-walkable" map. In fact, this would be a relative positional map since the 3D objects and "walkable" map seem to placed upon it. The field background however seems to be not affected by it, so it looks like the field background is placed first then this "mask" is applied. Everything else is then placed in accordance to this "mask"'s relative co-ordinates.

I also have suspicions to what the function of section 6 is. When a simple exchange in bytes was done, the whole background & all objects disappeared, so all I get is a black screen. The bg MIDI still loads. It seems that the objects are still around since you can still interact with them. I can't confirm if the character is still able to walk since even when I use "help" the arrow doesn't appear. Even the arrows that show the exit's don't appear. I have also been unable to exit from the field file. I'm not sure about this too, since I can't even see where I am in the first place (I could easily be running in circles). It does look likely though that section 6 somehow controls the exits and the layering. I have a feeling it's just the last black layer covering everything. Anyone have any comments?

ficedula · « **Reply #6 on:** 2001-07-03 22:09:00 »

SaiNt: Was that a request for me to make FFLZS accept wildcards?

No problem, I'll add that in straight away; it's a fairly easy change.

Speculation on the nature of section 2: since it's constant size, and has the effects you described, I'd conclude that it was the initial position of the '3d camera'. If so, changing it would move all the 3d parts of the level - items, people, exits - while leaving the 2d background unchanged since that's drawn straight onto the screen regardless. It's one possible explanation anyway.

It's probably coincidence, but the data in that section takes up 38 bytes. Each CAM file (which we pretty much agreed were movie camera files) has a 40-byte field per camera position. Might have nothing to do with it, but it's encouraging...

EDIT: Uploaded a new LZS tool.

[This message has been edited by ficedula (edited July 03, 2001).]

The SaiNt · « **Reply #7 on:** 2001-07-04 14:37:00 »

It seems you're right about the 3D camera thing.

Fice, would you mind finishing off what I started about section 2? I don't exactly have the time to edit one byte and recompress the whole flevel file several times to test the results. Now that we roughly know what it's about it should be easier for you to test?

I was thinking that I would move on to section 6 to test more stuff.

fice :-

Quote

Quote from your field file document
Section 4
After the length indicator comes another integer, also indicating length. Useless, but it's there.

I think it's a mistake of some sort, since if you count the size of the section from right after the first length indicator, you will arrive 4 bytes short of the next section. If you start right after the second length indicator, then everything will be right. It's pretty dumb but like you, I haven't found any variations to this yet.

Quote

Quote from your field file document
code:

00 Blank 2 bytes
0009 NumSections 4 bytes
? Section 1 location 4 bytes
? Section 2 location 4 bytes
etc. etc. etc.
[/quote]
Why is it that you always make
0000 four bytes and not 00000000 4 bytes?
Common mistake?

[This message has been edited by The SaiNt (edited July 04, 2001).]

The SaiNt · « **Reply #8 on:** 2001-07-04 18:07:00 »

Ok, today I took a look at Section 7

It seems that section 7 is of a constant size too, just like section 2.

The only difference is that section 7 is
48 bytes in size (not including the first four bytes / length indicator).

It also seems that not many files keep information in this section. Looking a little further, I've made a list of field files that I've looked through.

Odd files with info in section 7
ANFRST_1
ANFRST_2
ANFRST_3
ANFRST_4
ANFRST_5
BLIN63_1
BLIN65_1
BLIN671B
BLIN673B
BLIN67_1
BLIN67_3
BLIN1
BLIN2
BLIN3_1
BLIN59
BLIN69_1
BLIN68_2
BLIN68_1
CANON_1

Files with no info in Section 7
ANCNT1
ANCNT2
ANCNT3
ANCNT4
ASTAGE_A
ASTAGE_B
BIGWHEEL
BLINST_1
BLINST_2
BLINST_3
BLIN66_2
BLIN66_3
BLIN66_4
BLIN66_5
BLIN66_6
BLINELE
BLIN61
BLUE_1
BLUE_2
BLIN62_1
BLIN62_2
BLIN62_3
BLIN65_2
BLIN66_1
BLIN67_2
BLIN64
BLIN2_I
BLIN63_T
BLIN60_1
BLIN60_2
BLIN70_4
BLIN70_3
BLIN70_2
BLIN70_1
BONEVIL1
BONEVIL2
BUGIN2
BUGIN3
BUGIN1A
BUGIN1B
BUGIN1C
CARGOIN
CANON_2

Anyone see anything in common for the files that have info in Section 7?

ficedula · « **Reply #9 on:** 2001-07-04 19:30:00 »

Quote

Why is it that you always make
0000 four bytes and not 00000000 4 bytes?
Common mistake?

Yes I often miscount things like that when I'm not spending much time checking what I wrote.

The SaiNt · « **Reply #10 on:** 2001-07-05 13:10:00 »

Here's an update.

Most of the field files have a Section 2 of size 42 bytes. However, I have found out that certain files have different sizes.

The second thing is the confirmation of the function of section 2. It has been confirmed that Section 2 contains the Camera positioning information. It controls the angle and the distance of the camera. I'm guessing that this section stores camera positional information on a per object basis since there are certain field files with larger Section 2's

*EDIT*
Information mapped on Section 7

The first 4 bytes of Section 4 is the Length Indicator.

After that,

The first byte disables / enables random battles.
00 = Disable
01 = Enable

The 2nd byte sets the encounter rate
01 = High
FF = Low

The 3rd & 4th byte determine the enemy & background for the 1st possible enemy.
If you give a non available value, a debug battle will load.
It doesn't seem like the background is attached to the enemy.
But this two bytes do not work independantly.
Maybe it requires adding of the values of both background & enemy.

The 5th & 6th byte determine the enemy & background for the 2nd possible enemy.

After that, I assume that the list will follow the same accordance for enemy 3, enemy4, etc

There are a few odd values near the end of this section.
I'm guessing they set the probability of the enemy being chosen.

[This message has been edited by The SaiNt (edited July 05, 2001).]

The Skillster · « **Reply #11 on:** 2001-07-06 02:18:00 »

well all i have to say is....
WOWOWOWOWOWOWOWOOWOWOWOW

u know ive been waitin for this discovery for ages

now all i have to do is fix my shitty aTi drivers 2nite, and 2moro is my day off so im gonna crack on with testin this theory.
i pray that its correct

=======
refresh my memory, where do i find sections 4&7 inthe decompressed feild file

[This message has been edited by The Skillster (edited July 05, 2001).]

ficedula · « **Reply #12 on:** 2001-07-06 03:02:00 »

...that's what my field file format doc is for...

The Skillster · « **Reply #13 on:** 2001-07-06 03:49:00 »

no luck in there too
the closest thing was
0009 num..

? section1

? section2
.. ...
not much help actually
The Saint: where in the ff7 memory might these feild files be loaded into?

The SaiNt · « **Reply #14 on:** 2001-07-06 06:39:00 »

Skillster : No idea. If I knew, I could easily point out the problems in Cosmo's background viewing code, provided FF7 has already decompressed it in memory.

Fice: Hmm, Skillster doesn't understand. Maybe your doc was not clear enough? Anyway, fice, could you add this to Cosmo then Skillster won't have to understand it to use it

ficedula · « **Reply #15 on:** 2001-07-06 14:10:00 »

Tell you what: you fully decode the enemy section, and I'll do that

halkun · « **Reply #16 on:** 2001-07-06 20:10:00 »

Hey guys, I have just found the *clooest* PSX emu plugin that allows me to view the video memory, so I can see what get banked into where and when something loads. It also can wireframe all objects and I have made some rather intrestisting dicoveries.

1) Ok, opening scene, even before the movie starts, all the field textures are loaded, What's really cool is the eyes for the field models are loaded into thier own little section and blink automaticly while the movie is playing. (It's a random mutitasking fucnction) I slaf found out that there are *4* field layers, From front to back it's blue, pink, purple, and white. Also when a battle loads, the scene texture data overwrites the field textures and the level is loaded, but whale the camera pans about the level, the models are *not* loaded yet. They are cached. The textures are banked in and the models appear, but *THEY ARE NOT THE CORRECT COLOR* They white and trasperent. The textures are loaded and then immiadely the white transparent models appear and darken to thier correct colors. The enemys do pretty much the same thing. Oh and when a spell goes off, during the "warm up" sequence before the spell is fired, the spell texture is loaded into video memory and cached there until another spell is used. Then that overwrites whatever was there. At battle end the field texture data overwrites the mess left befind by the battle and the game continues.

ficedula · « **Reply #17 on:** 2001-07-06 21:49:00 »

Interesting ... but remember stuff isn't always done the same on the PC. For a start, I'm only aware of 2 layers of background in the field files ... maybe each layer is split into 2 parts, or maybe not; anything learnt from the PSX version *may* apply to the PC version, but not automatically.

The Skillster · « **Reply #18 on:** 2001-07-06 22:51:00 »

any progress on decodin the enemy info?
fice:
all i wanted to know is how to identify the start of the section 7 in the field file OR the hex location in a hex editor (ie: ultra edit) so i can try and tune/edit the enemy values.
thanks

ficedula · « **Reply #19 on:** 2001-07-06 23:34:00 »

Field files: Skip the first 6 bytes.

Then there's a 4-byte integer listing the offset for each section.

Ie. bytes 6-9, section 0 offset
bytes 10-13, section 1 offset
etc.

The Skillster · « **Reply #20 on:** 2001-07-07 01:29:00 »

u mean like a table of contents? or an index?

ficedula · « **Reply #21 on:** 2001-07-07 02:20:00 »

The Skillster · « **Reply #22 on:** 2001-07-07 02:54:00 »

dammit
im lookin at field file gonjun2
decompressed (gast)
and well the section 7 has an offset of 8100
and im struggling to find the right one :O
i mean, i dont think im searching the files properly, can any1 help?

Clone5 · « **Reply #23 on:** 2001-07-07 05:05:00 »

I'm having the same problem as Skillster. No matter how I look at the numbers or put the together or take them apart, I never get addresses that make any sense what so ever.
Why don't you show us an example. Here is anfrst_1.DEC to 0x2F:

Quote

00 00 09 00 00 00 2A 00 00 00 07 5F 00 00 31 5F
00 00 F8 63 00 00 08 80 00 00 58 A1 00 00 22 E1
00 00 56 E1 00 00 3E E4 00 00 D9 5E 00 00 02 05

Seeing what they are will definitely help next time.

EDIT: Thought HTML was on

[This message has been edited by Clone5 (edited July 07, 2001).]

The Skillster · « **Reply #24 on:** 2001-07-07 10:58:00 »

hold on thats the offset table.
i can tell u that u ignore the 1st 3 bytes:
000009
then the next 2 r offset for section 1, next 2 are for section 2 etc
buuuuut
in my case im lookin for a 8100 as an offset for section 7...

Author Topic: Bingo! (Read 16189 times)

CT-CyberTech

CT-CyberTech