Final Fantasy 7 > General Discussion

Where is all the data for the PS1 version of FF7 located?

(1/3) > >>

MysticLord:
I want to make some things like this but for FF7 when I'm done with the Ogre series.

I'm also curious if anyone has made any hacks that de-hardcode things, or expands tables, which can integrated with them, as well as the locations of names for digits (items, skills, materia) if it's uncompressed and can be easily integrated into the vlookup functions that generate previews.

I need explanations of each byte/bit too, or someone I can pester about the subject.

I don't care about animations or models, just data for things like skills, items, materia, enemies, encounter tables, and so on.

nfitc1:
I've got data for battle related stuff (except for encounter tables), but it's not super well organized. Every byte and most bits have documented functions too. Just tell me what you need and I'll work with you.

What de-hardcoding hack are you thinking about? It seems possible to un-hardcode some things with the right memory hooks. To my knowledge there are no such hacks for battle-related mechanics.

MysticLord:

--- Quote ---I've got data for battle related stuff (except for encounter tables), but it's not super well organized. Every byte and most bits have documented functions too. Just tell me what you need and I'll work with you.

What de-hardcoding hack are you thinking about? It seems possible to un-hardcode some things with the right memory hooks. To my knowledge there are no such hacks for battle-related mechanics.
--- End quote ---
I want to make spreadsheet editors for everything, so uhhh, give me everything is the best way to start I guess... but we can start with whatever you want to start with. I really don't know much about hacking FF7.

Though it seems you're talking about battle mechanics code instead of data. That's not quite as easy to deal with using spreadsheets, but it can still be very useful. Either way it can wait until later, as it's not that useful without data unless you're talking about a catch-all spreadsheet for battle mechanic hacks. Still, that sort of thing is better used as a commented and labeled disassembly.

Give me the data related to battle stuff - general 1 sentence description of what each table does, what file it's in, starting address, ending address, number of entries, entry size if fixed and entry delimiting scheme if it's not. That should be enough to set up a spreadsheet that can be used for editing. If it requires decompressing or has a subfile scheme, tell me where to find that tool and parameters for using it, as well as any byte massaging (delete bytes, add bytes, etc) I need to do to use it.

Then a description of what you think each byte per entry does, and as much of a breakdown on valid inputs for each byte as you've got. If it's too complicated, just post your unedited notes and I'll fill in what I can then hand it over to you for editing my notes, and of course you can use it to test things.

If the table is also found intact in RAM - or the entries are - in a location that is always the same place (like 0x13c00, always), then post that, because it will enable hot-patching of save states for faster editing. If your emulator has a special header, post that too.

nfitc1:
Let's start with something simple like items. What format do you want the data in? Can you give me an example?

I think I see what you're getting at. I haven't done much PS1 emulator hacking, but since the RAM is always the same it shouldn't be difficult to find the data. I know the entire KERNEL.BIN (where all the battle-related object data is) is always present in memory during battle so it should be in a static place each time. It can't be too hard to find it.

MysticLord:

--- Quote ---Let's start with something simple like items. What format do you want the data in? Can you give me an example?
--- End quote ---
1. File it's found in.
2. Starting address of data.
3. Ending address of data.
4. Number of entries of data if it's 1 entry per item, otherwise describe the scheme for delimiting it.
5. Number of bytes per entry if it's a fixed number per entry, otherwise describe the delimiting scheme for it.
6. Explanations of each byte.

Example of number 6:

--- Code: ---0x00: Item ID

0x01: Item Weight

0x02: Item Power
    : Context depends on if item is weapon, armor, or shield.
    : All skills that are present on this item use this byte to modify their formulas.

0x03: Strength modifier
    : Signed byte.

0x04: Dexterity modifier
    : Signed byte.

...

0x0C: Additional effects
    : This byte determines the context of bytes 0x0D, 0x0E, and 0x0F.
    : Values
        0x00: null
        0x01: weapon attack - 0x0D = element, 0x0E = status effect, 0x0F = critical rate
        0x02: weapon healing - 0x0D = element, 0x0E = status effect, 0x0F = critical rate
        0x03: Use skill 100% of time - 0x0D = upper 8 bits of skill ID, 0x0E = lower 8 bits of skill ID, 0x0F = bit 0x80 sets detroy on use, other bits unknown

--- End code ---

You don't have to type "0x" in front of all hex values, you can just say that all numbers are hex unless prefixed by a "d", or use the $ prefix for hex or what have you. As long as it's consistent, unambiguous, and you tell me your scheme it's all good.

I'm going to reread whatever you post a dozen times as I transcribe it into a spreadsheet and double/triple check it after that, so the only possible issue is something not being answered, inconsistencies, or mistakes. If the first two are present, I will definitely notice and ask for clarification. I might notice a mistake if it doesn't jibe with the data.

If it seems that something needs to be organized in it's own way (if - god help us - several bytes have values whose context is completely unique depending on several other values), then put that stuff with the byte that determines the context and leave a note for the stuff that very rarely changes context like "... unless byte 0x0c says otherwise".

So if byte 0x0c can change the meaning of bytes 0x00, 0x01, and 0x02 in a handful of circumstances, then add "see byte 0x0c for context dependent information" to bytes 0x00, 0x01, and 00x2; then identify in byte 0x0c's entry the circumstances where it does this.

Think of it as trying to reduce the duplications of explanations so you edit as few places as possible when you find an error or update something.


--- Quote ---I think I see what you're getting at. I haven't done much PS1 emulator hacking, but since the RAM is always the same it shouldn't be difficult to find the data. I know the entire KERNEL.BIN (where all the battle-related object data is) is always present in memory during battle so it should be in a static place each time. It can't be too hard to find it.
--- End quote ---
IIRC pSX emulator has a header 0x2b0 bytes long for it's save states, and all others have footers (so the address doesn't change). Addresses shouldn't be any different if it's a footer.


RE save states: If the data is exactly the same format for the PC versions, post the same info for them too... though you should only need to specify things that differ, like file and starting address.

If the data is a subfile in another file, is only ever accessed by doing math on the header of the file, and you can reasonably expect the change the sizes of the subfiles previous to it, then include an explanation of the header. I understand what little endian means, and have basically a sophomore++ level of CS education.

Navigation

[0] Message Index

[#] Next page