Author
|
Topic: The only thing worse than a newb... (Read 707 times)
|
Paladin_Hammer
Guest
|
 |
« on: March 31, 2007, 01:26:09 pm » |
|
Is being that newb and knowing it. Hi guys, I've decided its time to stop leeching off this site and contributing. I've actually been here for a month now, just downloading all the hacks you guys have made. Well its time to stop that.
I figured if I'm going to contribute, I'm going to need to start small. So I downloaded Hexadecimal Workshop and... got stopped. Exactly WHICH file (there is .FIG, .SRM, .ZS1, and .ZST) controls the values of character/enemies/bosses? Of course I've opened each of them, but I can't tell the apple or orange difference in any of them (hence me admitting my newbness).
If someone here knows which file contains the character info (this is FF6 btw) for HP, MP, and other stats, I'd really appreciate it.
|
|
|
|
« Last Edit: March 31, 2007, 01:47:09 pm by Paladin_Hammer »
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #1 on: March 31, 2007, 01:37:21 pm » |
|
I would guess that the information is in the .smc file itself. But, I've never done any stats hacking myself, so I could be wrong. I know that you can edit your party member information in the .zst files, but you also mentioned enemies and bosses, and that information wouldn't be in the .zst, it'd probably be in the .smc, I believe.
~DS
|
|
|
|
|
Paladin_Hammer
Guest
|
|
« Reply #2 on: March 31, 2007, 01:48:01 pm » |
|
My bad man the FF6 I have has only FIG, SRM, ZS1, and ZST. Sorry, but you did say ZST so I'll check that one out.
|
|
|
|
|
Gideon Zhi
Guest
|
|
« Reply #3 on: March 31, 2007, 01:58:25 pm » |
|
Stats are going to be in your rom (usually an smc, but in your case, the fig.) Stats that are _currently_ in use will be in your savestates (zst, zs1) and your party's current data as it relates to the game in progress (not their starting data) will be in everything except the rom. You might also want to check out the Getting Started section. |
|
|
|
|
Paladin_Hammer
Guest
|
|
« Reply #4 on: March 31, 2007, 02:01:27 pm » |
|
Stats are going to be in your rom (usually an smc, but in your case, the fig.) Stats that are _currently_ in use will be in your savestates (zst, zs1) and your party's current data as it relates to the game in progress (not their starting data) will be in everything except the rom. You might also want to check out the Getting Started section.Thanks for the input. I already checked out those guides, and they helped me understand just what all these numbers mean. The only problem I have left (I'm nearing my answer) is figuring out how to use Hex Workshop. but that should only take another half hour now. |
|
|
|
|
creaothceann
Guest
|
|
« Reply #5 on: March 31, 2007, 02:13:59 pm » |
|
.FIG
This is your ROM dump, judging from the extension made with the Pro Fighter dumper, but the extension doesn't say much. Other possible file extensions are: 058 078 1 bin dx2 eur fig jap mgd mgh sfc smc swc ufo usa. Emulators have their own routines to detect the actual file type.
You should scan your ROMs with NSRT (it has a graphical front-end), remove the copier headers and rename the files to ".sfc". IPS files (patches) that require a header can be adjusted.
.ZS1, .ZST
Emulator savestates that contain the entire status of the running console. They can be viewed and edited with savestate tools, eg. vSNES.
.SRM
Contains the content of the cartridge's battery-packed SRAM, ie. your in-game saves. There're also some tools for those.
|
|
|
|
|
Lenophis
Guest
|
|
« Reply #6 on: March 31, 2007, 03:08:31 pm » |
|
FF3usME can do character and monster stats. I'd suggest getting v6.31, since v6.40 was removed to excessive brokeness, and v6.41 isn't any better. Honestly, the beta is in better shape than either of these two versions. =\\ However, v6.31 also has a few issues which are excessively annoying as well: The file filter is broken, so it'll only detect the file extension ".smc" It doesn't like roms without headers (Lord J hasn't implemented it yet). So if you remove it like creathcaenn suggests, FF3usME won't work. There's a memory leak in the formations editor. Don't keep clicking on the "show" checkbox to switch between highlighting and not highlighting monsters in formations. There's a memory leak with renaming monsters. Once you rename about 9 or 10 of them things will really start to crawl. The names aren't compressed, and are at CF/C050 (hex offset 0xFC050, add 0x200 if a header is present). They are 10 bytes each. The special attack names are right after the monster names, also 10 bytes each. Monster HP is capped at 65,535 HP. However, Master ZED assisted CRK and CRK made a patch to give monsters 24-bit HP (caps at 16,777,215). It's not perfect though, as if they recover any HP while above 65,535, they will die due to overflow. I can't seem to find that patch on the net right now, but I'll upload it for ya a little later. If you wish to edit the monster stats manually, they are at CF/0000 (hex offset 0xF0000, add 0x200 if a header is present). Each monster is 32 bytes, and there are 384 monsters. Hope that helps.
|
|
|
|
|
Paladin_Hammer
Guest
|
|
« Reply #7 on: March 31, 2007, 03:21:32 pm » |
|
FF3usME can do character and monster stats. I'd suggest getting v6.31, since v6.40 was removed to excessive brokeness, and v6.41 isn't any better. Honestly, the beta is in better shape than either of these two versions. =\\ However, v6.31 also has a few issues which are excessively annoying as well: The file filter is broken, so it'll only detect the file extension ".smc" It doesn't like roms without headers (Lord J hasn't implemented it yet). So if you remove it like creathcaenn suggests, FF3usME won't work. There's a memory leak in the formations editor. Don't keep clicking on the "show" checkbox to switch between highlighting and not highlighting monsters in formations. There's a memory leak with renaming monsters. Once you rename about 9 or 10 of them things will really start to crawl. The names aren't compressed, and are at CF/C050 (hex offset 0xFC050, add 0x200 if a header is present). They are 10 bytes each. The special attack names are right after the monster names, also 10 bytes each. Monster HP is capped at 65,535 HP. However, Master ZED assisted CRK and CRK made a patch to give monsters 24-bit HP (caps at 16,777,215). It's not perfect though, as if they recover any HP while above 65,535, they will die due to overflow. I can't seem to find that patch on the net right now, but I'll upload it for ya a little later. If you wish to edit the monster stats manually, they are at CF/0000 (hex offset 0xF0000, add 0x200 if a header is present). Each monster is 32 bytes, and there are 384 monsters. Hope that helps. Helps a bunch  . But as far as editing the actual Hex goes, I can't figure out where the offsets for character stats are in it (I'm using Hex Workshop). Terra's is located at 221B for her level (so I am told), I find 221B but I can't figure out how to edit it, I tried writing over the "FF" in 221B's spot, BUT, 221B's info is exactly this in Hex Workshop (with "_" representing empty space): __FF. I'd assume FF is the value for her level, but since "F" represents 16, well, it makes no sense that that is her level! None at all! How long did it take you guys to figure out how to edit ROMs in Hex (more specifically levels and stats). I just want something to gauge my progress by. |
|
|
|
|
StIoachim
Guest
|
|
« Reply #8 on: April 01, 2007, 02:23:11 pm » |
|
But as far as editing the actual Hex goes, I can't figure out where the offsets for character stats are in it (I'm using Hex Workshop). Terra's is located at 221B for her level (so I am told), I find 221B but I can't figure out how to edit it, I tried writing over the "FF" in 221B's spot, BUT, 221B's info is exactly this in Hex Workshop (with "_" representing empty space): __FF. I'd assume FF is the value for her level, but since "F" represents 16, well, it makes no sense that that is her level! None at all! If it's FF (255 decimal), it makes no sense, so I would asume the address you are reffering to (221B) is not for anyone's level. How long did it take you guys to figure out how to edit ROMs in Hex (more specifically levels and stats). I just want something to gauge my progress by.
If you are editing savestates (.ZS*) or SRAM (save) data, the thing you can do is to write down the current values of what you want to change (a esay start is current/max HP) in the game, and search them in the file using your hex editor |
|
|
|
|
Aerdan
Guest
|
|
« Reply #9 on: April 01, 2007, 02:26:47 pm » |
|
Be aware that multibyte data is stored in little-endian. That is to say, 256 HP would be stored as 0x0001, not 0x0100.
|
|
|
|
|
creaothceann
Guest
|
|
« Reply #10 on: April 01, 2007, 03:29:50 pm » |
|
No, it would be stored as 0x0100 but displayed by the hex. editor as "00 01". Don't give him ideas about "how freakin' wrong little-endianness is" etc.  |
|
|
|
|
Disch
Guest
|
|
« Reply #11 on: April 02, 2007, 01:43:25 pm » |
|
Don't give him ideas about "how freakin' wrong little-endianness is" etc. Werd. Actually... I find that from a programming and just a general logic standpoint, little endian makes waaay more sense and provides several advantages. The reason people feel little endian is backwards is because the commonly accepted method of printing numbers is opposite from the commonly accepted way of calculating numbers. That is... people read "35" and want the most significant digit to be printed first. Conversely, however, when confronted with a logic/calculation problem like "13632+19", most people will perform the logic on the least significant digits first. Little endian is consistent. Just as bit 0 is the least signficant bit in a byte.... byte 0 is the least significant byte in a word/dword. Just as a bit has a weight of 2^n... bytes have a weight of 256^n. Logical -- consistent. Big endian borks all that up. Not to mention the issues big endian has when truncating numbers in programming languages. Consider the following C example: typedef unsigned char byte;
short var = 0x0102;
byte trunc;
byte* ptrunc;
trunc = (byte)var;
ptrunc = (byte*)&var;
logically -- you would expect trunc to == *ptrunc.... which on little endian, it would (they'd both be 0x02). However on a big endian system, *ptrunc would be 0x01, while trunc would still be 0x02. </craaaaaazy tangent> |
|
|
|
|
|
RHDN Forum Archive
