Bingo!

[Clone5]

I've just realized that I've misread Fice's field-format document.  For some reason I thought that the... No wonder I wasn't finding anything.  Oops. My mistake.

[The SaiNt]

Let me put this in a clearer form.

Let me take the example of my favourite file    

MD1_1

Remember to decompress the file first.

Next you have to understand my shortform system.

S   Start of file
NS   Number of sections
S1   Section 1 offset
S2   Section 2 offset
S3   Section 3 offset
S4   Section 4 offset
S5   Section 5 offset
S6   Section 6 offset
S7   Section 7 offset
S8   Section 8 offset
S9   Section 9 offset

Now, look at the starting section of the file I've given below.

code:

S---+ NS--------+ S1--------+ S2--------+ S3--------+ S4--------+ S5--------+ S6--------+ S7--------+ S8--------+ S9--------+ Section 1 Starts here
00 00 09 00 00 00 2A 00 00 00 A1 2E 00 00 F1 2E 00 00 17 32 00 00 27 50 00 00 E7 5B 00 00 07 94 00 00 3B 94 00 00 23 97 00 00 73 2E 00 00 02 05 .. .. .. etc

[/quote]

Ok, so it looks clear now right?

But that's not all!

You have to remember that the PC reads stuff the opposite way around.
Now look at the section I labelled S1.
The value is 2A 00 00 00.
Since the PC reads stuff the opposite way around, the value should actually be read as 00 00 00 2A.
The second thing to remember that this is a hex number so when you use the "GOTO" command in your hex editor,
So, remember to select hex and not decimal.
If you goto offset 2A, you will arrive at the section I've labelled "Section 1 starts here"
Not use the same method to get to section 7, ok?

Fice has explained this before but I'm sure most of you didn't pay attention of were not around then.

Ok, back to my documentation of Section 7.

The first 4 bytes of Section 4 is the Length Indicator. So far the size of Section seems to be a constant size of 48 bytes.
In fact, I don't even have to look at the other files to tell you that there shouldn't be a different size of it since there is no indicator at all to tell where the offset for "low probabilty "(see below) is.

After that,

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

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

Values in between 01 and FF also work, the values were only given as an example.

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, so you don't have to be afraid of testing values here.

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

After that, I the list will follow the same accordance for enemy 3, enemy4, etc till the end of the section.

FF7 randomly chooses an enemy and sort of cycles through the list of enemies listed in no particular order.

Values that appear from offset $E onwards, have a very low probablity of occuring. It seems to be less than half. So far, all values that appear here seem to be for back attacks and attack from both sides.

Enemies facing backwards are defined as different numbers.

That means meeting an MP and meeting an MP with back attack uses different values.

If you specify the enemy twice in the list, you increase the probability of that enemy appearing.

The game reads the list in order.
If you have no value for enemy1, but a value for enemy2, when you encounter enemy1, a debug battle will appear.
This means that if you wish to have 4 enemies, you will have to define it in enemy1, enemy2, enemy3 & enemy4
If you define it as blank, enemy2, enemy3, enemy4, enemy1, the game will assume you have 5 different enemies.
And should it load blank, you will get a debug battle.
So in general, you shouldn't leave spaces in-between.
However, you can leave empty spaces from the last enemy to offset $E since offset $E defines the "low probability" battles.

So, you can have:-

code:

Length----+ BE RB E1--+ E2--+ E3--+ E4--+ E5--+ E6--+ LPE1- LPE2- LPE3- LPE4-
30 00 00 00 01 80 2D 61 2E 59 2F 49 00 00 00 00 00 00 30 11 30 11 00 00 00 00

[/quote]

BE Battle Enable
RB Encounter Rate
E1 Enemy 1,etc
LPE1 Low probability enemy1,etc

Here are examples of some values.

2F 49   MP + Dog with Mako Reactor Background
2E 59   Dog with Mako Reactor Background
2D 61   2MP's with Mako Reactor Background
30 11   Dog facing your back with Mako Reactor Background

Unfortunately, it is impossible for me to list all the of the numbers for the enemies since it will involve me modifying each field file to only load one type of enemy.
Thus, it is even more impossible for me to give you an algorithm of how to calculate the enemy types and the backgrounds unless someone can provide me with a list of the values.
I know for sure that there must be an algorithm to find the make enemies appear in different backgrounds since I managed to make Shinra Soldiers that appear in the Shinra Building to appear on the background where Sephiroth fights the dragon (raining).
In fact, Ive even gotten the debug triangles to appear in the train graveyard. This however does make one thing clear, if you put values that are really small, you are very likely to get the debug triangles. If you get a single triangle, that is counted as an encount error and it means there errors in the numbers you have provided. If you manage to get more than one triangle appear with no background, that is not considered a debug error since you get a background. Maybe that's the only way to find out what values appear for which backgrounds.

So, fice is this enough to get you to put this "feature" into Cosmo?

Currently, I'm forced to compile the whole field everytime I make a single change to any field file and this is a lot of hassle since I have to decompress and recompress the field files everytime I do this.
I could continue to do it this way, but you guys will have to wait a long time to get a full listing of the values.

I'm in a rush now and I'm trying to complete my research paper which I have to hand up by Friday so I'm running low on time. So, I doubt I'll be working on the field files for a while so if any one wants to go ahead and help me finish it go ahead, ok? If you guys would rather wait for me, I'm fine with that too. Actually, the next section I was gonna look for was for the shop info. I was sort of thinking of identifying all the easier stuff first so I will be able to find out which section the scripts are held in.

I'll still answer any questions about this section though.

Sorry bout stretching the table again, but this is the only way I can think of formatting it cause HTML is off.

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

[ficedula]

Possibly ... I'll do a bit of work on it myself.

Incidentally, all of you DO know you can modify the levels while FF7 is running and have it recognise the changes? That's what I do, I just realised some people might not have been aware you can do that...

[ficedula]

An observation: The values aren't absolute. In other words, a particular value might give you Shinra MP/Midgar road in one place but not in another.

Specifically, I was looking at the two train graveyard levels and the sewers before them. I copied the sewer encounter section into the train graveyards. In graveyard one I got Shinra soldiers. In graveyard 2, I got the same encounters as from the sewers!

So I guess each level has a particular 'environment'. This determines which set of encounters and backgrounds it uses. Between levels with the same environment, swapping encounter values gives you exactly the same encounters. Otherwise, it doesn't. No, I don't know where the 'environment' is defined.

[The SaiNt]

I've gotten conditions like that too but most of the time it's caused by copying and pasting the whole section. Usually, if you clear all the battle values in the section (make all of them 00), and add the values one by one, they should be the same. If each level file had it's own set of enviroments, that would go against the idea of being able to have a forest background, Midgar road, raining background, shinra building, train graveyard in the same field file. I don't remember the exact values, but I managed to get all these different battles working within the same field file.

If what you say about the values not being absolute is true, it would mean that somewhere within the field file, there should indeed be an "enviroment" section. But that doesn't make much sense either, since if there was an enviroment, I would only define only one or two backgrounds per field file. The only reason I can think of for there being different "enviroments", is to divide them into "pool1", "pool2" ,"pool3" etc. This way graveyard 1 will have access to "pool1", and most field files within this area will use "pool1" as well, to help cache and reduce memory usage. When another field requires access to "pool2" of the enemies, it will overwrite "pool1", and most of the field files near it will use the same pool as well. Get the general idea?

You guys probably might have some other opinions, but I think this is where we need some people to help out thinking of the structure of the field file before we can go any further.

[halkun]

MID1_1 is the first field file right? I'll get to work.

[Skillster/RedSarg99]

wow i got it!!!
im finally learning  
trust me to have a REAL go at finding the enemy numbers  

[Skillster/RedSarg99]

hmm
check this out
on a shop level in gongaga
2481 in the enemy 1 section gives u a fight with a BIG GREEN dragon (aka the 1st sephiroth fight in the flashback) plus the background matches with rain AND the camera panning). heh, with my level i got wiped out  

[Skillster/RedSarg99]

im gonna look into the memory mappin of that section
asuumin ff7 maps the whole or part of the section into memory and then reads from it.
thus we can change enemy fights "on the fly"   enabling documention of the enemy+background codes...
damn, magic trainor creator dont work in win2000

[ficedula]

You can already edit stuff on the fly in a hex editor ... or at least I can. That's why I specifically mentioned it earlier on, in case somebody didn't know how to. Does this mean, somebody doesn't know how to?  

[Skillster/RedSarg99]

yea i figured it was possible
buuuuut
the section is uploaded in to the memory, but it also CHANGES location if u exit that scene then reenter it (ie to refresh the data- as it gets reloaded from the cache).
sooo
i basically copy/pasted the section 7 values in to a memory search tool and viola.
i can edit the values (as long as im in the same scene) and the corresponding fight occurrs. buuuuut unless u FILL all the enemy sections u WILL get loads of debug fights too.

so, basically thats my findings for today. found out 3 other enemy values. ill guess that the enemy squad+background ARE linked.
you all know this allready but hey, i wasnt too involved b4 so now im catchin up  

[The SaiNt]

Hmmm...
Skillster, are the offsets for stuff kept in section 7 constant? If they are, then I can get to work this weekend decoding more of the field file format since this speeds up editing a whole lot compared to editing the files themselves.

[Skillster/RedSarg99]

ok wot ive seen is
from the 3-4 feild scenes ive looked at
(md1_1, gonjun2, gunwa2)
the offset section at the start defines the correct section 7 offset.
thus section 7 is loaded into a random part of the feild cache memory in ff7 (just a name for the area it loades feild files into) then it is read from. right. the section 7 values ARE IDENTICAL to those present in the feild file. thus the pc basically decodes and uploads it all in one go. so just search for those first 15 values of section 7 (3000000001ff...) and ull find the memory location. then u can edit it  
but sometimes when u RE-ENTER the scene, the data is loaded into another part of the cache memory.

[ficedula]

I've been doing it using a hex-editor ... go into FF7, enter the location ... leave it and ALT-TAB into my hex editor; edit the file, and update the LGP using FFLZS/FFLGP; ALT-TAB back into FF7 and enter the location again, the changes will be recognised if you've done it correctly.

[The SaiNt]

Ok, Skillster, if the offset is not constant, I know for sure at least one offset must be constant. The pointer to that address.

Since I might not get the time to do it, I need you to help me do this. Use some kind of memory viewer, (the debug mode of VC++ works fine of even memoryhacker) and browse the values above and below the section 7 defined in memory. See if it matches the order in the field file. If it does, go look for the offset that points to the offset of the beginning of section 7.

However, if the bottom and top sections do not match the field file format you're gonna have to do it the hard way and search for values in memory that equal the offset.
For example, if the beginning offset for section 7 is 00DAF010, you must look for a value in memory that has the a hex value of 00DAF010. If you can identify that offset of the pointer, you won't have to do searches in future.

BTW, fice, it's a whole lot easier modifying memory values than having to use FFLZS everytime. I used a method nearly exactly to yours to test for the existance of section 4 and 7 and boy did it waste a lot of time. Especially, when all I needed was to change one value because I forgot to.

[ficedula]

Not really. Change one value? ALT-TAB to hex editor, change it and save (Ctrl-S), then recompress it (2 keystrokes, I've set up a shortcut). It's not really that slow!

[Skillster/RedSarg99]

ok saint:
confirmation that the WHOLE feild file from the start to the end of section 7 and beyond IS uploaded to memory starting from address:
4FC605C
thats not a fixed pointer thou, but yes the whole feild file is THERE.
what i really want to know is if thats the data the game uses or is that just a temporary storage for the decompressed field files which might get sent elsewhere for use...
========
fice:
i alt tab out to my memory wacther, edit a value then alt tab back in, that REALLY isnt slow  
-----

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

[The SaiNt]

Ok, I've got the address of the pointer
Field File Ptr 00CF0C44

For those of you that don't know how to use the pointer here goes.
The field file ptr is at 00CF0C44.
Now use a game utility like gamehack or anything else and key in the address 00CF0C44.
Now, make sure gamehack reads it as 4 bytes.

Now, the value that appears at this address is the address for the beginning of the field file in memory.

This explanation of mine isn't turning out too well. Tell me if you guys still don't understand. I'll try to think of another way to state this.  

[Skillster/RedSarg99]

i get u , lets see how to say it.
that numba up there is the "address" of the "page number" for section 6, ok?
u tell a memory editor/game hack thingy to add the "address" to its list or search for the "page number" then using the number in there u just move down that many bytesto find the "location" for section 6 info.

remember how a PC reads data , ok? backwards, one byte at a time.
---------
i was completley wrong  
i see now.
the pointer points the the memory address where the field file IS STORED
no wonder.
so it always changed location for u too>?

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

[The SaiNt]

Ok guys, I've found out what section 8 does too  

Section 8 defines the "exits" in the field file. I haven't mapped out it's structure yet though. Await news from as soon as I find more free time.

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

[Skillster/RedSarg99]

ok i await with eagerness