Scene.bin Revisited

[Terence Fergusson]

Thought I'd go back over this since... well... we *knew* the basic monster data before hand, but there's a lot more interesting stuff to the Scene.bin structure to be looked at.  Here's what I know.  (Note: this is not going to go over Scene.bin *itself*, but rather the 256 files it holds, each of which relate to certain groups of monsters....)

First, battle numbers.  We have 1024 possible battle numbers: 0 - 1023.  Each group of *4* Battle Numbers refers to a particular Scene file: for instance, Battles 0-3 refer to File 0 in Scene.bin, Battles 4-7 refer to File 1 in Scene.bin, and so forth.

Now, here's the basic structure of the individual files that are compressed and contained within Scene.bin:

Code: [Select]

0x0000: Enemy IDs (2 bytes each, 3 records)
0x0006: FF Padding (2 bytes)
0x0008: Battle Setup 1 (20 bytes each, 4 records)
0x0058: Battle Setup 2 (48 bytes each, 4 records)
0x0118: Battle Formation (16 bytes each, 4 sets of 6 records)
0x0298: Enemy Data (184 bytes each, 3 records)
0x04C0: Attack Data (28 bytes each, 32 records)
0x0840: Attack IDs (2 bytes each, 32 records)
0x0880: Attack Names (32 bytes each, 32 records)
0x0C80: FF Padding (512 bytes)
0x0E80: Enemy AI Offsets (2 bytes each, 3 records)
0x0E86: Unknown (26 bytes)
0x0EA0: Beginning of AI Data, starts with 6 bytes of FF
0x1E7F: End of Scene.bin
And... that's pretty much it.  So far, I know that Battle Setup 1 includes information for multiple battles; 0x08-0x0F is a group of four words that say which possible four battles will occur *after* defeating the current battle (note: it may be that there's more information here that prevents sequential battles from happening unless the battle engine is assigned to a particular mode, since sequential battles are mainly used for Battle Arena).  The battle ID 999 (0x3E7) is generally used as padding, and should never be called... though I'm not sure whether that's hard coding or a different bit set in Battle Setup.  The next battle is picked randomly out of the four IDs given, anyhow.

Most of the rest is self-explanatory or I haven't looked deep enough into.  Have fun!

[halkun]

Gears only has 0x0298-0x0344 documented (Enemy data)

I remeber seeing more posted about things like ebemy X-Y-Z location and formations... I'll put what I can in there....



:::EDIT:::

Gears has been updated with the new scene.bin data.

[Terence Fergusson]

Thought you'd like to know that I've tracked down where standard random encounters are held for field files: they're in Section 7.  A brief overview for those who aren't sure about the format of the field files:

0x0000 = Blank 2 bytes
0x0002 = Number of sections (4 bytes), always 9
0x0006 = Pointer to Section 1 (Dialog/Event, what the script dumper deals with)
0x000A = Pointer to Section 2
0x000E = Pointer to Section 3
0x0012 = Pointer to Section 4 (Palette)
0x0016 = Pointer to Section 5
0x001A = Pointer to Section 6
0x001E = Pointer to Section 7 (Encounter)
0x0022 = Pointer to Section 8
0x0026 = Pointer to Section 9 (Background)
0x002A:0x-4 of Section 1: Length of Section 1, where Pointer to Section 1 points to
0x002E:0x00 of Section 1: Start of Section 1 data, continues for the number of bytes specified in 0x-4

As stated, Section 7 is the Encounter listing, and is generally 48 bytes long (not including the Length dword).  I've not even started to decrpyt what the other bytes mean around there... I suspect encounter rates and other things.  Each encounter is stored something like: xxxxxxxx yyyyyyxx, where the 'x's are the standard Battle ID we're familiar with, and the 'y's are something connected to that specific encounter.  Encounters where you can get ambushed appear to be held seperately from the others, too, starting at... what... 0x14?  Unsure.

Anyhow, feel free to play with it.  I remain disappointed that this has yielded no trace of Ho-chu in Ancient Forest... was hoping it would at least be some really rare battle or something....

 ===

EDIT: Few more notes on the Encounters section.

First, *EVERY* Field file's Encounter section is 48 bytes long (52 if you include the size).  It's then split into definite partitions:

0x00: Encounter Data 1, possibly enounter rate in 2nd bytes?  (2 bytes)
0x02-0x0D: Encounter+Chance(?) bytes, as stated before.  The total of the 'Chance(?)' bytes for this part always adds up to 64 if encounters are possible.
0x0E-0x17: Secondary encounters.  Sometimes blank, sometimes gaps.  No clue on the chance bytes, or how it relates to previous data.
0x18: Encounter Data 2, same setup as Encounter Data 1.  Very often blank, no idea what this data is for.
0x1A-0x25: Encounter+Chance(?) bytes for Encounter Data 2.  Again, adds up to 64.
0x26-0x2F: Secondary encounters for Encounter Data 2.  Again, no idea what it's used for.

To get more information, I'm going to have to go and start changing things, but thought you'd like an update on what I had for now.

Funnily enough, it seems that Tonberry got as far as making it *into* some random encounter data... unfortunately, it's in a scene-only room - trnad_51 : The room where Sephiroth is encased in the center of the Whirlwind Maze - and never gets a chance to be called.  What a pity....

By the way, also had a brief look at the World Map... although things are different between that and the field files, it naturally has many of the same data structures... dialogue's in 'mes', the event files are in 'wm0.ev', 'wm2.ev' and 'wm3.ev' (I assume... though I've not gotten any conclusive proof that this is the case through a *brief* glance through them), and the encounters are stored in 'enc_w.bin' (but may or may not follow the same rules regarding encounter chances... unsure yet)

[Terence Fergusson]

Well, enough data to warrant its own post to follow.

Encounter data for the World Map starts at offset 0xB8, and each section is 32 bytes each.  A section is defined as follows:

0x00: 01
0x01: Encounter Rate (1 byte)(?) (lower numbers mean higher encounter rates)
0x02-0x0D: Normal Battle+Chance of that battle (2 bytes each, 6 records)
0x0E-0x15: Special Formation Battles+Chance (2 bytes each, 4 records)
0x16-0x1F: Chocobo Battles (2 bytes each, 5 records)

Again, the chance byte for normal battles seems to always add up to 64.

Anyhow, as for how they're *stored*...

...each area in the game has four fields, and they're aligned something like this:

Area - Grass
Area - Dirt/Snow
Area - Forest/Desert
Area - Beach

And the areas are naturally in this order:
Midgar Area
Kalm Area
Junon Area
Corel Area
Gold Saucer Area
Gongaga Area
Cosmo Area
Nibel Area
Rocket Area
Wutai Area
Woodlands Area
Icicle Area (Not sure what Forest is for this, since the forests in this area are supposed to have no encounters)
Mideel Area
North Corel Area (Materia Cave north of Corel)(?)
Cactus Island
Goblin Island (Goblin Island lacks a full empty Beach encounter list)

Anyhow, enjoy.

[Lord_Skylark]

Ho-chu/Otyugh does exist as a battle in the ancient forest - but whether the game is programmed to ever call up this battle I do not know for sure. A long time ago I used a game shark code that would change which battle was called when a random battle was triggered and there is a battle for Ho-chu/Otyugh in the ancient forest - I've never gotten into it in the actual game, but I've forced the battle with this code (same with a regular Tonberry on your first visit to the northern crater). I used to have a list of which enemies were in every battle which I found out by using that code 1024 times or however many battles there are,  but that was when the game first came out and I have no idea where that is any more. (I do happen to still have my ff8 one that I did in the same manner)

~Sky

[Terence Fergusson]

Correction, Skylark.  It exists as a *formation* which uses the Ancient Forest background.  And it's with the Ancient Forest monsters.  But I've dumped *all* 1024 possible encounters, and dumped *all* possible random encounter data for *all* field files.

Ho-chu's encounters isn't in any of the random encounter lists.

[Lord_Skylark]

Do you have the full list of what encounters and the % to call up each encounter is for each area on the overworld + each screen inside each "dungeon" then? I'mg uessing that's what you were saying.

THanks,
~Sky

[Terence Fergusson]

I have the full list, yes.  I've also got the %s for *standard* encounters, but as I said earlier in the thread, there are also non-standard encounters (for things like being ambushed on both sides and the like) where I don't know how the % is figured for.

As I said, Ho-Chu's encounters are not in *any* of the lists, and the Tonberry encounters are only in *one* room that you're never allowed to walk around and encounter battles in.

 ===

Anyhow, been working on the AI data recently.  Not gotten *much* done, but I did nail more parts around 0x0E80:

Code: [Select]

0x0E80: Enemy AI Offsets (2 bytes each, 3 records)
0x0E86: Start of AI Data
Now, what I didn't understand at first.  AI Data *begins* with a list of offsets for that data: it's usually 32 bytes worth, but most are dummied out with FF padding.  Enemy AI is split into sections, much like previous FFs did.  The first few sections appear to be "Setup", "Main", "Counter:Damage", "Counter:Death", "Counter:Physical" and "Counter:Magical" (in that order).  A specific mob doesn't have to have any of these sections except possibly "Main"; if it doesn't have that section, it'll be listed as FF FF in the offsets.  The offsets themselves then point to the correct code relating to that section.

In the sections themselves, I've only nailed down *VERY* few things.  This is what I know:

60 and 61 usually denote that a byte or word follows respectively.  However, there's limited places where this is actually used (for 60, at least, since it tends to be used for other things in other opcodes; 61 seems more unique in use though).

93 denotes the start of an FF7 String.  It is terminated with FF.

70, 71 and 72 denote a jump.  They are always followed by a Word address which is *where* in that section it will jump to next.  For example, 72 00 00 would jump right back to the beginning of the section.  72 *seems* to be unconditional jump, while the other two have conditions attached to them... not sure exactly what or how it checks yet.

73 denotes the end of the current section.

That's pretty much it right now.  I'll post more if I figure out more.[/code]

[Fremen^SF]

Maybe someone may remind of me, I was working on SCENE.BIN file there's about one year ago, and after a long break, I decided to continue my work about deciphering this file in order to release a document about it.

But before that, I wanted to ask you if you've already found new information since the creation of this topic ? It would be a shame to do things you've already done

Thank for your answer, and again, excuse me for my english mistakes. ^^