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?
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...'.
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).]
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?
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).]
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 from your field file document
Section 4After 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 from your field file documentcode:[/quote]
00 Blank 2 bytes
0009 NumSections 4 bytes
???? Section 1 location 4 bytes
???? Section 2 location 4 bytes
etc. etc. etc.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).]
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?
Why is it that you always make
0000 four bytes and not 00000000 4 bytes?
Common mistake?
Yes :wink: I often miscount things like that when I'm not spending much time checking what I wrote.
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).]
=======
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).]
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 :)
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.
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.
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).]
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:[/quote]
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 .. .. .. etcOk, 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 = EnableThe 2nd byte sets the encounter rate
01 = High
FF = LowValues 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:[/quote]
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
BE Battle Enable
RB Encounter Rate
E1 Enemy 1,etc
LPE1 Low probability enemy1,etcHere 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 BackgroundUnfortunately, 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).]
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...
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.
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.
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 :wink:
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.
[This message has been edited by The Skillster (edited July 10, 2001).]
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. :)
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).]
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).]