 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by Zeld |
| Pages: 1 2 3 |
| User | Post | ||
Zeld Red Paragoomba                   Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I recently got into rom (and ram) hacking somwhere around the middle of last summer. I first became competent when I reached the Gameboy Advance emulation stage, where Visual Boy Advance's expert tools made it possible for me to...do stuff. Of course, the tools mainly helped me in making gameshark codes, which is always nice, but not very large scale. I decided to actually get into the rom, and I was able to find weapon data for a couple of fire emblem games and even some uncompressed graphical data in fire emblem 8, which I proceeded to replace with a custom portrait of my original RP character. I made him too short, but I was able to properly align the mouth frames and make him look like he could talk and blink. That was cool. It's unfortunate that even though I found the weapon data myself, some hackers on a Fire Emblem forum not only found this data before me, but compiled a table editor in Nightmare to allow hacking noobies to edit weapon data as well. Of course, their editor doesn't allow for custom weapon effectiveness like mine does. I took their editor and spiffed it up a bit. Ok, jsut one feature, but...whatever. Also, I can't post a picture of my character being in FE 8, because not only would it be easy for you all to say that it was photoshopped, but I made the mistake of writing my character's portrait over a princess' graphical data when testing my tile editing ability, and the scene I was viewing to see how well the mouth frames worked involved some palading calling me a princess. It's too embarassing to post, as such.
I got rather cocky and decided to start a large scale patch for Fire Emblem: Rekka no Ken (the 7th in the series) in which the character of mine along with some of my forum buddies were the main antagonists. So far I have customized the weapons and obtained tools for decompressing and recompressing graphics and text. I haven't bothered to look for map data yet, though I may do so when I'm done hacking the animation data. I have found some animation data, but so far all I am able to do is reorder the frames of the battle animations and change the delay for how long they appear... I have fiddled with other games too, of course. Minish Cap is another of my favorites; I have found map data for it (it's uncompressed, yay!) and I've made a serial repeater code that checks to see if you have swung your sword, and, if you are, it reduces all enemy HP to 0. So, yeah, swing your sword, everything dies. Good stuff. Except for that one boss that has his weak point on a different map...using the code isn't too smart for him, no. Here's a pic of some ram in Minish Cap; it's centered on the sprite data of the moblin who's shanking me in the background. 
You'll notice that the address is in the x3400000 range; the picture was taken back before I was aware of the ram loops. I know them now, of course, but back then I didn't. Oh well. Would have saved me loads of time in making GS codes if I had known that I only needed to dump x48000 bytes. In Link's Awakening for Gameboy, I was able to get into some sprite data and set enemies on fire compulsively. I wanted to do that in Minish Cap. Turns out I can't, but I ended up logging that other stuff, at least. I made some gameshark codes that let me move enemies around with the D pad, but I never got around to making a complete list of input oriented codes to allow complete control over enemies. It seemed pointless. Perhaps if I knew enough assembly and gained access to a tool that let me write assembly scripts to my minish cap rom I could create some sort of new aspect of gameplay that involved "mind control". Anyhow, that's basically my accomplishments. I haven't done much else other than make codes for games to where pressing in a direction makes you go in that direction incredibly fast. You know, "walk faster" codes, except in a platform game the codes enable you to fly. They also serve as a sort of walk through walls code. In addition to those types of codes, I also make codes that allow a character to escape the lag from performing an action. This is especially awesome in the Megaman Zero series, where I can make Zero go from swinging his Z saber slowly to doing 15 attacks per second for an entire level/boss fight. Seamless combos. So, that's what I've done. I plan on getting into making Nintendo 64 gameshark codes, and want to make an infinite hitstun code for Ocarina of Time and Super Smash Brothers, but I don't have the right tools for that stuff yet. Hacking those roms to edit maps and stuff seems too far beyond my computer, me, or both at the moment... |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I don't have any utilities for Nintendo 64 emulation that work that great in making gameshark codes, and I can't find any, either. I found something that was almost good enough, but not quite: a custom 1964 emulator that dumps ram and stuff. Well, dumping ram is an awesome feature, but if it can't LOAD the ram I can't tell which parts of the ram are responsible for what I'm trying to hack.
I'm tired of Ganon bashing me around while I'm levitating over him, and decided I wanted to make an infinite hitstun code (infinite health is overrated). When making codes for GBA games, I just used the memory viewer that comes with VBA to load sections of dumped ram to isolate the address of things such as hitstun, etc. Can't do that with my N64, no. So, I decided that I should try mixing savestates to achieve the same effect, because I can LOAD savestates. But a savestate address doesn't match a ram address, so making a code this way would be futile, unless I knew more about savestate addresses. Can I get some insight into N64 savestates? Is there a better tool that can load ram, removing the need for screwing with savestates? Am I an idiot for asking this stuff when I should be finding and hacking the animation data for the Fire Emblem patch I started?  |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I'm currently working on a fire emblem patch myself, which I have decided will include custom battle animations. I'm going to give my character a...sniper...rifle.
Don't laugh! Anyhow, I've found some semblance of animation data in the rom using unLZ but it's only part of it. See, at the address e8aca0 there is some data concering the Hero's animation. This data includes how long the frames are displayed and some flags for things such as the white flash generated by striking an enemy and I think there may even be some flags for sprite rotation. Frie Emblem 6 made wicked use of sprite rotation for the battle animations...anyhow, also in this data are these 16 bit values...if I switch these 16 bit values around with each other, I can manage to reorder the frames of animation of the Hero's attack. But I don't want to reorder the frames, I want to edit which tiles are used in the frames and where they appear on the screen in relation to each other. I found this particular animation data by searching through the rom with unLZ and finding the graphical sheet for the Hero. I noted that the address was at e83e58, and searched for that value in a hex editor, thinking that it would be pointed to. Well, it is, but the data that points to it is compressed. Luckily, I found the pointer anyway, because the first time that value appears in the compressed data would have to be uncompressed so that the rest of the compressed data can associate with that value...I read a little bit about sliding window compression, but I'm no expert, so if I sound dumb...it's because I am. Anyhow, I found the pointer and used unLZ to decompress the data at the address closest to that point. Later on, I went into battle and viewed the WRAM and saw that all of the data I had found was right there. Now that I was able to screw with data while it was in the WRAM, I didn't have to worry about screwing my rom or losing data from compressing uncommon bytes. I know that sounds retarded, because last I checked LZ77 was supposed to be lossless. Maybe it was just my inability to recognize 8 bit and 16 bit values for stuff that made the game freeze so much. Yes, when I was fooling around with the data I would change single bytes at a time to witness the results, without thinking that the byte I was changing was part of a 2 byte value, and that I needed to change two bytes to a value used elsewhere in the data in order for it to not freeze the game. So, I've come awful close to making custom animations, but not quite. I can't think of how to find tile and X, Y position data for those tiles and I'd like some help, and since Zephyr and IOS are also looking for help in working with animation, I thought it would be a good idea for us to help each other. That said, I think I've seen some spell sheets in the rom data, but they're all off by themselves away from everything else. The issue you two are having reminds me of my issue; in my patch for FE 7 I debated with my friend who should get to use the Ereshkigal animation. I decided to let him have it and gave myself gespenst since I already ahd flametongue. I plan on rewriting the sheet for flametongue and turning the fireballs into sniper shells, then rewriting the data that compiles that sheet into the animation the dragon pwns you with into something more rifle-like. I took the liberty of converting those two spells into sword type weapons. 
I didn't like having to surrender the most awesome dark spell animation to my friend, and I wanted to find a way to share it with him. This can't be done unless we hack the spell animations that the weapons use or if I decided to unPrf the weapon from my friend. Unfortunately, I'm too tied to the idea of my friend and I having our amazing weapons Prf'd to us alone - they're our unique weapons and no other class can use them. I want to keep it that way, so hacking the animation is probably for the best. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| Yes, I'm aware of the compression. PJ64 simply zips them with the same compression method that winzip and winrar do, which I believe is LZ77 or some form of it. Too bad I can't tell winrar to unzip GBA roms so that I don't have to use unLZ...not that unLZ is bad.
Anyhow, I decompressed my PJ64 savestates and copied the data from one over the data to another and didn't have any problems loading the savestate, so the compression isn't a problem. The order that the bytes are saved is. Thanks for the link, although having read that it doesn't work for PJ64 makes me worried that the emu it does work for may be one that my computer doesn't get along with. Edit: my winrar doesn't work on 7z files anymore (if it ever did). I can't use that thing. Is it even a program or is it a custom emu? (edited by Zeld on 11-07-06 04:11 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| My friend wants me to hack weapon strength in Megaman Zero 3 for GBA. Now that I know that a debugger is a much better tool for finding this data than what I originally planned to do, I decided to set a breakpoint for everytime a value was written to a Boss's HP. So I go and hit the boss, and there's my breakpoint. I disassembled the instruction it returned and didn't see anything that appeared related to subtracting 4 HP from the boss.
I'm not sure what else to try. Or if I even read the instructions my debugger output correctly XD Having failed that attempt, I equipped an "elf" that supposedly increased the strength of my weapon by 1 damage. I tried to isolate a byte that was affected by this increase in the ram and was going to set a breakpoint on it, but I couldn't find such a byte because the thing I equipped to raise my attack power didn't raise it at all. I was still doing 4 damage. Stupid game...*grumble* Somewhere in all that screwing around I did I saw an address whose value was FC. "Oh, hey, that's the same as negative 4. Maybe this has something to do with it." Well, it doesn't. The only thing I found was the ram address that contains the value for which weapon you have equipped in your primary slot. The secondary weapon byte was immediately after. I don't recall tracing that byte, but I probably wouldn't have found what I was looking for anyway. I guess I should just do a generic instruction log from some time before attacking a boss to some time after and look for the arithmetic involved. If the reason I didn't notice any subtraction of 4 previously has to do with my incompetence with assembly then it won't help to do a log, so hopefully that wasn't the issue... If there's anyone who knows a bit about this game and things related to dealing damage or increasing weapon strength that could lead me to some relevant bytes, I'd appreciate it. |
|||
|
Zeld Red Paragoomba  Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| In that first paragraph in my first post I mentioned setting a break on write to the Boss's health address. That would be 203be44. I had already made my own gameshark code to fix the value at 1 in order to make one hit boss kills, but gameshark codes are too easy to make, and I wanted to do something challenging.
Yes, I'm starting with the Z Saber. Perhaps I should try a different weapon? Not that it should make a difference... Something weird happened; in my first post I mention that when I tried setting a break-on-write that I didn't find anything useful. I may still haven't found something useful, but I went back to the address my debugger turned up. 8007cbd, if I recall correctly. Here the value is 4. My debugger was giving me a logical shift left instruction of register 1 to register 1 (I don't know what logical shifts do exactly, but since the value was x0409 at the address 8007cbc and in binary 0409 is 000 00 10000 001 001, it moved some value to the left by 16 bits). Is shifting a value left 16 bits the same as multiplying by 65536? Anyhow, I changed the value from 0x0409 to 0x0509, which I calculated to be a change from shifting the data left 16 bits to shifting it 18 bits. Being in the incomprehensive stage that I am, I have no idea why what resulted from this occured, but for some reason the boss I was fighting, Omega, would die in one hit. Typing in 1009 killed ME in one hit when I took damage. Changing it to still other values had no effect at all, and there were a few other values I tested that also killed the boss in one hit. But why is shifting this data just a small amount more or less allowing the boss to die in one hit? It clearly has nothing to do with how much damage I do. If moving something left two bits is the same as multiplying by 4, and I do 4 damage, that would yield 16 damage and the boss was dying in one hit even with 64 HP. I doubt setting a break on read of 8007cbc will help, but like I said, I don't know what I'm doing much at all, so I just try stuff. Edit: Gross. I reported that stuff all wrong. Turns out that changing that byte to 05 was making it shift left 4 more bits instead of 2. That's multiplying by 16, and 16 times 4 is 64. So that could explain the boss's instant death, except setting the byte to 05 doesn't cause the boss to die instantly. Setting the byte to 0x10 causes both the player and the boss to die when damaged. I don't remember what other values I tried or what the results were. I should pay more attention... Edit 2: I was running out of ideas, but I decided to set a breakpoint on the boss's hitstun instead of his HP since HP wasn't getting me anywhere. I tried looking through the rom for values like 4 and fc near the address that the previous breaks kept giving me (8007cbc) and I found this one weird address that controls how many frames the game pauses when you hit the boss. Dunno if anyone who's played this game has noticed it, but when you hit enemies the game's processing pauses for a moment, I assume this is supposed to be a dramatic effect for emphasizing that you damaged the enemy. So, I can change how long that pause lasts. At least I could. I didn't care about it, so I just forgot the address. Anyway, I set a break on write to the boss's hitstun and it gave me an address. The following instructions didn't look fun, so I typed d 8007cd0 in order to disassemble about 16 instructions or so in front of that. At the very bottom of the instructions that were listed I noticed "mov r0, #0x5a". Well, having seen from typing "n" to continue instructions from the breakpoint that 0x5a is the value that goes into the hitstun byte before it decreases back to 0, I quickly discovered that changing the byte at the rom address 8007cf7 from 5a to 00 makes bosses not go into hitstun. At least, bosses that use 203be44 for their HP byte, which is most of them. So now, instead of using a gameshark code to fix boss hitstun to 00, I have this nifty little assembly hack that allows for infinite combos. You can damage the boss as fast as you can push the button. And...well, autofire .
I STILL want to find weapon data though. Edit 3: WOW that was fast. My Z saber does up to 255 damage now.
I disassembled 16 instructions prior to the hitstun thing and saw "sub r1, r1, r0". Well, I had noticed that when the debugger broke on write-to-203be44 that register 0 had a value of 4, equal to how much damage I did, and register 1 had a value equal to the boss's HP. So I immediately recognized the subtraction as the damage and typed in 3908, for sub r1, x08. And I tested it and my Z Saber did 8 damage. So I added a 1 in front of the 8 and it did 24 damage. This is pretty sick, yeah. Oh, you probably want the address. 0x08007cb8. There you go. Have fun wit dat Edit #472: ARGH NO DON'T HAVE FUN WITH IT Yeah, um, those addresses are dangerous. Just like how that weird instruction I was messing with at 8007cbc, where both the boss AND Zero died in one hit, the hitstun and damage addresses are both tied to Zero and the boss. Setting the 5a to 00 at 8007cf7 makes megaman get infinite combo'd as well, and if you change the instruction at 8007cb8 from subtracting a variable to subtracting an immediate then both Zero and the boss will take that much damage when they are hit. And since there's no hitstun, and the beams omega shoots are uber slow, even just doing 9 damage to me kills me instantly even with my HP at 255 because the damage just stacks so fast...I should go and edit the instruction that loads my Z saber's strength into r0 instead of editing what is subtracted from r1. Stupid me. Another edit: My friend made a game written in C and gave me the script so I could look it over and see if I recognized what each script did. He told me that he programmed the damage calculation so that the player's ship (it was an asteroids type game) would take damage each frame that it was in a collision with a meteor. So, the damage is calculated by how long the player is caught in the collision. By changing the hitstun to 0 and the damage to 1, I've created a similar damage calculation for Megaman Zero 3. Unfortunately, omega's beams move slowly and are big enough to do around 7 damage per hit. And my HP caps at 16. This is not good XD I think I like this version of damage calculation better than the version with hitstun, although infinite hitstun codes are fun to make and games without hitstun take that away. 
Uber Edit: Ok, I took full advantage of the "last" option of VBA-H to track how much damage I do to the address 203a8ef. I wasn't finding anything storing to that address within a few previous instructions, so I set a break-on-write there. It turned up some nice results, but then I traced my damage to another ram address, 203a905. I was starting to get a bit pissed off, so I set another break on write at that address. This time, instead of disassembling a few instructions before my result to look for a store, I noticed a rom address in the registers and went to it. There was all my damage values right there. Of course, all the values were double the amount of damage you actually do in the game, because, as I noticed during my tracing, damage is halved during the calculation process. So unless you were to edit this part of the process to make damage not be halved, the most damage you can do by editing your weapon strength is 127. Here's the address I've logged so far: 835b89d - Z Saber Neutral Aerial Strength 835b898 - Z Saber Neutral Ground Strength In my Minish Cap weapon hack I included a log of part of the damage routine for those interested. Well, the parts of the damage routine for Megaman Zero 3 are so long and spaced apart that it'd be more of an annoyance than a cure for curiosity. (edited by Zeld on 11-08-06 07:06 PM) (edited by Zeld on 11-08-06 11:26 PM) (edited by Zeld on 11-08-06 11:28 PM) (edited by Zeld on 11-08-06 11:40 PM) (edited by Zeld on 11-08-06 11:53 PM) (edited by Zeld on 11-09-06 12:17 PM) (edited by Zeld on 11-09-06 12:31 PM) (edited by Zeld on 11-11-06 04:09 PM) |
|||
|
Zeld Red Paragoomba  Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| Yes. I like to hack weapons.
Ok, I failed my attempt to hack Megaman Zero 3's Z Saber weapon strength. After the success I just had, though, I'll probably try looking through the script again and tracing back a bit further to reattempt finding where my weapon strength is loaded from. I was able to do just that for The Minish Cap. I'm attaching the log I recorded and read through that showed me where the rom address for my sword's strength was. I felt really retarded, too, because I started reading from instruction 35 in the log, the one that subtracts damage from enemy health, and going backwards looking at each instruction that applied to the register with my weapon strength in it. I eventually traced it all the way back to the VERY FIRST instruction, not even noticing prior that the first instruction I logged was the one that loaded my sword's strength from the rom. Here's the instruction my debugger crapped out when I set a break on write to the enemy's HP: 80178fc - Enemy health subtraction instruction from teh damage And here's the address I found that controls how strong my sword is. I saw a pattern in this vicinity with increasingly higher numbers which I would venture to guess is the strenth of the other swords you get. 80ba384 - Level 1 Sword Strength <3 thumb Edit: if you change the subtraction instruction from 1a45 (sub r5, r0, r1) to 2500 (mov r5, 00) then everything dies in one hit. Not that you couldn't figure that out on your own, but...well, there's doing 255 damage, and then there's doing enough damage to kill everything in one hit regardless of how much health it has... (edited by Zeld on 11-10-06 04:33 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I'm working on a fire emblem 7 patch; have been for some time. I had sorted out how to hack text, graphics, and stats pretty fast and decided that I had plenty of time to make custom battle animations as well.
Contrary to most peoples' understanding of how animation data is stored, Fire Emblem 7 (actually, Fire Emblem in general) does not have individual pictures for each frame of the animation. For it to be that way seems illogical to me, and the way that it is stored, that is, with a graphical sheet of tiles and nearby data that calls these tiles and gives them an X and Y position on the screen makes much more sense. I imagine it's much easier to condense. Anyhow, I found all of this data. The data that arranges the tiles, the tiles themselves, how long each frame lasts, and the special flags that call events such as the white screen flash from hitting an enemy. I haven't found rotation flags in this data, but I'm sure it's in there. But I'm having a problem; I searched for a string of the X and Y position data for the tiles of the Hero class's Sword animation in the rom. I searched for only the first few bytes, knowing they wouldn't be compressed, even though the rest of the data is. I found a match and opened unLZ-GBA to go to a nearby address and decompress the rest of the data, but unLZ didn't find it. What the hell? Are there other compression methods? What really gets me is that the similar data for the Hero's Hand Axe animation is nearby, and unLZ-GBA found it no problem. I'm including the folder I've been keeping my findings attached to this post; a bunch of ram dumps and a couple of decompressed rom dumps, etc. Perhaps someone with more experience can give me a method for decompressing the animation data for other animations in instances where unLZ fails, because I'm positive I've found the data, and being able to edit it is essential for making entirely customized animations. Well, actually, I could throw the custom stuff at the end of the rom after expanding it with a bunch of empty space and find some way to point to it. But I've never hacked a pointer table before so I don't know how to find one in the first place. Tips on that would be nice, too. Also, in the pictures in the folder, the first picture is a result of me editing the animation data while it was in the ram, and the second is also from editing the ram, except I found that data in the rom as well (it's the file called "3167"; a rawdump from unLZ). The data I edited for the first picture is somewhere near the address I mention in the text file "animation tile7"; that's where I found the first of two matches (the second match being at the location labeled "wtf mirror?") is in the rom. Like I said, I can find it, but I can't edit it because unLZ won't recognize it, even with a deep scan. I even tried editing the SPR file that contains pointers to compressed data generated by unLZ and tacked on a pointer that I thought was the beginning of the compressed data. All that did was crash my hex editor. Edit: I decided to quit being lazy and searched for the addresses of the animation data I found and I think I've stumbled upon the pointer tables of the data. Now, I think I have enough data to construct my own custom battle animations. I don't plan to compress my custom animations because I'm afraid something bad will happen if I do. So, before I get to writing my own animations, I'd like to know if the decompression instruction that the game usually runs on this data will interfere with my animations by trying to decompress data that isn't even compressed. I'm pretty sure that the function will recognize that every single byte is uncompressed and leave it alone, but it'll be awhile before I've decompressed some data, moved it to the end of the rom, and pointed it, in order to test if that will be a problem or not. Ugh, I hate compression...I can't wait to finish my patch, damn compression getting in the way... Oh, I never bothered to try telling unLZ to write to a custom address. I don't know why I didn't think of it earlier. The game doesn't recognized that the data is already uncompressed just as I had feared, but I can compress my data to solve that problem anyway. The problem I have left is being able to hack existing animations, and all I really care to do is make custom ones. I could use custom animations to replace existing ones as well as adding new ones anyway. Now comes the tedious programming part...and the spriting...I'll have to make the sprite sheet first, since I'll need to refer to it to program the tile arrangement... (edited by Zeld on 11-13-06 10:31 AM) (edited by Zeld on 11-13-06 05:30 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I've found all the animation data in the rom and I can just use ram snapshots if I need it to be decompressed. Only problem being that I can't tell where the data in the ram ends, just where it begins.
I suppose I can do a half assed hack of all the types of animation data for a single battle animation and post a patch here, to give a small example of all the stuff I can do with the data I found. So far everyone that's hacked battle animations for Fire Emblem has only edited the graphics and not the animation. Is there a patch file that can make patches for roms of different sizes? Making custom animations means adding space at the end of a rom, and lunar ips doesn't make patches that compensate for a change in file size. I could always tell people how many 0s to add to the end of the file in order for the patch to work, but that seems like a step that can be skipped with the right patch maker. (edited by Zeld on 11-14-06 04:16 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I'm that one guy who's making an FE 7 patch (not FE 8; that was Zephyr). Remember me? No?
Aw. Well, I got around to tracing the battle routines that load damage and subtract it from HP and stuff like that. At the rom address 802944c is a command that loads a target's health into register 2, and following that is a command that loads the assailant's damage into register 1. The next command subtracts register 1 from register 2 and puts it into register 0, then stores the result into the ram and eventually to the target's HP byte. Somewhere in there the target's death conditional ensues... I went and changed the two commands at 802944c and 802944e to a long branch to the address 83fb210. And there, I slapped on this baby: First Script Lo and behold, whichever character with a portrait whose pointer matches the value that is in place of that "(=$08bdfdd4)" will be invincible. Not only that, but whoever attacks them will die gruesomely regardless of statistics. F'hax! Edit: Now that I think about it, a nice "BX LR" would probably save a couple of bytes for that last command. Not only that, but BX LR sounds like BXR, the move I invented in Halo 2 the day the server update made that glitch possible (maybe I didn't find it first, but I found it on that same day, so I take credit for it anyway >.>). Therefore, it sounds much cooler. BX LR. Kinda rolls off the tongue. I guess I can change it later... Second Script ^Added more code to remove the flaws the first program could not address. Invincibility :3 Great for a Black Knight effect, except this code is too brutal. It doesn't just make the character invincible; it kills off those who oppose them. The Black Knight was strong enough for it to be about the same, though. Edit: I forgot to mention, the second picture is of code that is linked to by a later process than the first; namely, the one at 8029c32. (edited by Zeld on 12-03-06 12:59 AM) (edited by Zeld on 12-03-06 01:04 AM) (edited by Zeld on 12-03-06 09:27 PM) (edited by Zeld on 12-03-06 09:28 PM) (edited by Zeld on 12-04-06 01:34 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| Fire Emblem.
This would be for FE 7, a.k.a. Rekka no Ken, or the Blazing Sword. First Fire Emblem to be released in the United States. I love it to death. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I noticed an ldr in some original code that, if I recall correctly, loaded a word from before the command. I tried to do that to make both programs refer to a single word, but uh...that didn't happen. Is that possible or was I just seeing things? I thought GBATEK said that the offset for an ldr could be signed...
Yeah, I could have pooled it afterward, but uh... Crap, I should just rewrite 'em both. I'll have to remember to do it that way the first time when I get around to interrupting the battle statistic routines in order to reach the 65535 damage limit (which, with a critical hit, would total 196605 damage. Whee!) Well, messy branch hopping aside, the routines together work perfectly. In case you're wondering, the programs are invincibility programs because I have a growing god complex and want my character to reign supreme >.> Edit: I took out the branches and literals and recalculated the other branches, then, put the literals at the end of the scripts and had them draw from there. I went from loading from 8 different addresses to 3. It's all nice and efficient now. Not to mention, I no longer have to change more than 4 digits in order to change who is blessed with invincibility. I'll have to change all 8 digits if I expand the portrait table, though. My contemporary project, along with my patch, is to universalize expansion of this ROM and throw out a patch with some binaries that will give other FE 7 hackers the ability to start with a fully expanded ROM. In that patch I'd like to include coding for custom skills. Other additions would be nice. Perhaps I should get a team instead of doing that by myself, though. It'd be easier to get suggestions and stuff. Anyway, here's the script updates: ... or not imageshack is down!(edited by Zeld on 12-04-06 01:41 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I planned on attaching the file, but I didn't see a way to in the edit window (not that I looked very hard).
That ought to do it... These two programs I went through the trouble of optimizing will probably be canned, since they were supposed to be gameshark proof and they certainly aren't. How would one go about programming gameshark codes permanently into the game? I spent some time looking for ram addresses that were constantly changing and using gameshark codes on them, and I found a few bytes that out performed the gameshark. Would interrupting the write process to those bytes allow me to program gameshark codes into the game that supercede a real gameshark? Also, these codes you speak of...hookshot from any distance? I never knew most of those codes existed. Simply googling for gameshark codes doesn't work (and according to lololol 2.0, "google" isn't a word, much less a verb). Could you maybe...hook me up?... |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| Is ARM 9 really that similar? I had guessed that it would be and wanted to get into DS hacking, but this computer can't even run a DS emulator past 3% speed. My other computer runs it at about 30%, but there's no transparency support. I can't tell if it's my graphics card or if the DS emulators are just not complete enough.
I have been assembling by hand (doesn't bother me at all) even though I do have goldroad. I decided to mess around with goldroad and I couldn't get it to compile even one instruction (probably because I'm not even close to being a programmer and just got into assembly hacking the day I read labmaster's post in the FE 8 Spells and Skills thread started by ZephyrShakuraus). I believe Zephyr mentioned something about spell animations and their association with weapons in that thread. Well, I was basically wearing a  face when I saw what labmaster had done to find the critical hit bonus, so I did what I did best back then and found a byte in the ram that determines which spell animation to play. I skimmed labmaster's debugging process and conformed it to my needs and found the data that associates spells with weapons, and made a module for it. Somewhere around this time I found weapon data for Minish Cap and MM Zero 3. That all happened within the past...month, I guess. So I'm really just a novice. I didn't get into hacking at all until the beginning of last summer, and now I've gone from making gameshark codes to making them permanent.
Wouldn't copying a gameshark's process of inserting writes only make the similar process of the permanent codes in the rom to run at the same speed? I want to outwit the shark, not tie the race
Edit: Also, you've got it backwards, labmaster. The gameshark DOES over write it faster than it triggers. I'm trying to beat the shark, not help it. Of course, the same soultion applies...I need to move my processes to be just before the crucial moment I'm trying to change. The problem is, I didn't do that, because I put my processes in front of the last write, but I should be putting them in front of the last read, because the game shark overwrites my process before the value can be read and used accordingly. 'nother edit: In lieu of my need to interrupt the process that kills of the character rather than the process that writes their HP, I dug into the death routine for enemy units (my character is going to be an optional boss, so I need to focus on making enemies unkillable). While player units are killed by setting the lowest two bits of the twelfth byte from the first byte of a unit's data, enemy units are pwnt by having their portrait pointer erased. However, if you directly erase a portrait pointer of an enemy and put your cursor over them, the game will freeze. There is some other routine that stabilizes it. I don't know what it is, but if you press A on a unit that you can move to bring up the movement field, then press B to exit, you can safely select the enemy that you killed with direct ram editing. Except you won't select anything, because they'll be dead. That actually doesn't matter because I'm preventing the process that zeros the pointer, so I don't have to worry about inserting something that would stabilize the dead character. I thought I'd mention it anyway, since I thought it was interesting... I was happy to see that the player's unit data pointer is in the registers during the process that kills off the enemies. It will make it much easier for me to keep the process the way I had: not only preventing my character from being killed, but killing off those who attack him. Once I get those permanent codes put in, people will have to play the game instead of erasing my character from the map and killing off my allies. The object of the single chapter my character will appear in will be to survive, since killing me is worse than killing Fargus (at least, I plan to make it that way). The irony is that the player will be inclined to let me kill them- my battle animation is going to be worth watching over and over again. I've been working on it for about a week or two...once the gif is done I'll have to deal with converting it into FE's animation data format, but at least I know how to. Mk, I plugged in some half assed code I made up and hand coded in like, 5 minutes, into the death routine. It worked, and even deflected the gameshark codes that pwned my last two programs to uselessness ( ). It's also only 32 bytes in size, including the 4 used for the literal and the two between the end of the script and the literal that couldn't be used. <3(edited by Zeld on 12-05-06 02:46 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I decided just last summer that I wanted to hack ROMs without using an editor that someone else worked hard to make. I got tired of people calling themselves hackers for being able to use others' tools, and wanted to learn how to do it on my own using tools that weren't game specific...like a hex editor.
Another interesting poll would be "which hex editor did you start out with"? My answer would be AXE version 3.4, one that most people seem to have never heard of... I was only able to find this "AXE" through use of this particularly interesting site called "Google" XD |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| This is for Fire Emblem 8, Seima no Kouseki.
People who play the Fire Emblem series know of the battle system; I imagine Advance Wars and other TBS's use a similar system: You have statistics that give you a chance to hit the enemy, a chance to get a critical hit, a chance for a special ability to activate, etc. The numbers that your stats are compared to to determine success or failure was called the RNG, for Random Number Generator. Well, there is a number generator for all that stuff, but it most certainly isn't random. I decided to call it the FNG, for "Formulated Number Generator", and then I hacked it to little tiny pieces and got the formula. Here be it; I'm not sure if it's the same for all FEs or not: Last FN=(First FN)*2{+1}) eor ((Middle FN)*2048+(Last FN)/32) and 0xFFFF) The {+1} is not executed if the First FN is less than 0x8000. "What are the First, Middle, and Last FNs?" Good question. FN stands for Formulated Number; what the FNG produces and the correspondent of an RN in an RNG system (I don't believe a true RNG exists, but we can theorize here). Naturally, they're stored in the RAM and can be fiddled with. They are stored at 0x3000000, the beginning of the Gameboy Advance's IRAM. Each is a half-word in length, and the FN labeled "First" is at 0x3000004, while the "Last" FN is at 0x3000000. So, it is right to left. The fact that the GBA uses intel byte ordering makes it even more right to left
During the FNG process, the First FN is used for comparisons to determine the outcome of a battle or w/e the case may be. Then, the formula above is executed. The Middle FN becomes the First, the Last FN becomes the Middle, and the result of the formula becomes the Last. Rinse, repeat. Each level in the game has its own separate start-up formula. If you hard reset the game and look at the FNs that result after each level's start up formula, you could calculate millions of FNs with which to play through the level with inhuman foresight. I thought this would be an interesting find to share with you all, but I only got into hacking out the formula because I need it for programming a new skill into FE 8. I've made a patch that gets rid of the hard-coded associations between certain classes and certain skills, and that provides bit tables where the user of the patch can freely decide which classes get which skills. But those skills are already in the game. I'm gonna add custom skills
The one I am working on now is called "Continue/Adept"; it allows the bearer of the skill to attack twice in a single turn if the skill activates. (edited by Zeld on 12-20-06 11:27 AM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| I finished programming the skills Adept, Astra, and Vantage into Fire Emblem 8: The Sacred Stones (Seima no Kouseki) for gameboy advance. Inspiration for these skills came from similar skills of the same name from Fire Emblem 9: Path of Radiance (Souen no Kiseki) for Gamecube.
Adept has a chance to double the number of attacks you receive for a turn, after the Brave Weapon bonus is added. Astra has a chance to add 4 attacks, and Vantage has a chance to set the number of attacks you have (for the first turn only) to 0 if it activates against you. It sets the number of attacks you have to 1 if the character who it activates for is unable to counter attack, because in cases where vantage sets the only attacker's attacks to 0 the game will freeze. The game also freezes if there are more than 6 attacks in a battle, so I added onto the programming to subtract the number of attacks a character has in a turn until the total is 6. Requirements for having the skills are setting the appropriate bits in the bit tables for which classes have the skill, and having an activation rate that totals higher than the number generated by the game's formula. The formulas for your activation rate are as follows: Adept activates with a percent chance equal to half of your skill added to half of your speed, plus an additional 10%. The total chance of Adept activating is thus 40%. Astra activates as often as Adept, except without the 10% bonus. Vantage only activates for a defending character. The formula is (half the defending character's skill plus their percent chance to avoid the incoming attack) minus (the attacker's skill (not halved) plus the attacker's chance to avoid the potential counter attack). This formula forces you to have a terrain advantage in order to use the otherwise broken skill. It adds strategy and makes more sense. Don't you think? Anyway, here's the patch. It contains reprogramming for all the old skills as well, in order to change which classes have which skills. Now all skills are interchangeable and combinable among the classes. (edited by Zeld on 12-22-06 10:50 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| Well, hopefully if any moderators see this they can move it for me so I don't have two topics floating around...
Every time I look in the RHRR I see all these nice editors that people worked months on and feel like the stuff I do is too pathetic to put there, but I'd say this little patch of mine is probably worthy. It just seems like that forum is "pure" and doesn't need a bunch of little hacks cluttering it up and interfering with the more important stuff. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| Did you consider that it may be compressed? I expect a Final Fantasy game would be extensive enough to make text compression the better choice, but I have no problem doubting myself on this belief.
If it's just encoded, I imagine a hex editor with a relative search could take care of this issue fairly easily. That is, assuming the font table isn't arranged in some ridiculous order so as to completely encrypt the text. But then, you would simply have to find the font table to determine the relative distances between each character's (or characters', if this game uses Dual Tile Encoding) hypothetical hex value. You can probably just Google "relative search" if you don't know what that is. Now, if the text is compressed, knowledge of assembly and use of a debugger will likely be your method of locating the text. Then comes the problem of decompressing it. If you discover the compression method by viewing the SWI used in the decompression process, you may be able to decompress it. If you're like me, and completely fail at anything that has to do with compression, you may have to reprogram the decompression routine to simply read the text as-is, and then expand the text by editing the pointer table and retyping all of the text by hand. If you don't plan on changing all of the text, you would have to make the decompression conditional, or just learn how to decompress it. (Am I saying this to you, or to myself? )
The first thing I hacked in a ROM was weapon data for Fire Emblem 7. I looked at the stats the game reads to you when you press "R" (the info button in this game), and searched for strings of numbers I saw. Unfortunately, I didn't know what order the stats were stored in (and the game's help window didn't make it apparent), so I took 4 numbers, and began to arrange them in any of 24 possible orders. About the 7th order I tried (  for luck), the hex editor found a match, and there was my weapon data.
That's the lame way to do anything. Best thing to do is to just trace with a debugger, but if the game explicitly gives you numbers, you should use that to your advantage to gain speed. Don't worry about pointers. In my personal opinion, it's the easiest thing to deal with. It's like, "Hey this data doesn't fit. Wait! Now it does! In your face, pathetically small ROM." The best part of all this is that FFTA is for GBA, and I specialize in GBA hacking. I should be able to help you quite a bit...in fact, I think I'll nab this game and do a bit of offset logging myself. I do have other things I plan to do for several other games, and college/high school classes to do homework for, so I won't have much time. I'll try anyway, though. Edit: I think I'll address the vocabulary word "Structures" real quick. Because of programming issues (i.e. incredibly obvious logical issues), data is often stored in "tables". In such a table, the same type of data will be repeated at a fixed interval with minor differences that discern each entry into the table. An example is the class data of Fire Emblem 7. It is "structured" to where every 84th byte, starting with the 4th byte of the first entry, contains a "class ID" number that determines how a unit looks on the overworld map (their graphics). In Fire Emblem 8, this number is also used to determine which skills the class has. I did an assembly hack to mess around with this and make skills more interchangeable among the classes (well, actually, they just plain weren't interchangeable at all to begin with). Anyhow, the "entry size" of the table is 84 bytes, which is 54 in hex. So, from the first offset of the table, 0xBE015C, you could add 0x54 to get the first entry. I should not say it this way, however. See, you must start at 0. The first entry is entry 0. The entry you acquire by adding 0x54 is not the first entry, but it IS "entry 1". Try not to be confused. Just think: "Start with 0". Anyhow, you add 0x54 and get 0xBE01B0. This is the first real class data's starting point (class 0 is a NULL class). I said the 4th byte contained Class ID. Well, add 0x4, and you will get 0xBE01B4. This is class 1's ID. You want class 2's ID? Add 0x54 again, because that's the entry size- the amount of bytes that each entry consumes (thus forming a "structure", because it's all nice and organized). 0xBE0208 is the Class ID byte for class 2. Other things to note about structure: Sometimes the data won't be in the form of a table, but it's data. It has to be organized somehow, or the game won't be programmable. Usually in cases like this, there will be bytes called "flags" that tell the game what to do with the next bits of data (haha, bits. That was a nice pun). You will need to recognize numbers that are repeated in certain types of data, as they may be flags. If those numbers are anywhere else, they may as well be useless, but where they are at in particular gives them meaning. Thus, you have "structure", because location gives the numbers meaning. That's all this stuff really is...numbers, and where they are. Or, if you want to get technical: electricity, and where it is stored. I really do type too much. 'nother Edit: That last edit was not only the opposite of what I said it would be ("real quick"), but it's almost the same size as what I had typed originally. Actually, I think it may be bigger, since my first post was full of empty space to give organization and legibility to the post. I guess I just fail at compressing anything (even my forum posts). Relative search failed. The text is either grotesquely encrypted or compressed. If it's both, then Nintendo is off their rocker. (Actually, yeah, they are.) Dang, even the font table is compressed. Also, judging by how the text appeared in the tile viewer, it looks like that first capital A and that next lowercase w are two letters of a single character. Which means DTE. It may or may not be compressed, but it seems to be DTE'd, and that is going to be a pain. "st" is most likely one of the DTE characters, so perhaps instead of looking for the word "stuck" I should look for "uck". Unfortunately, such a tiny string would be difficult to find a proper match for, assuming there is one. Not only that, but ck is likely a DTE character as well. I'm gonna debug it later if I get interested again, but for now I think I'll look at something else. (edited by Zeld on 01-16-07 01:03 PM) (edited by Zeld on 01-16-07 01:08 PM) (edited by Zeld on 01-16-07 01:21 PM) (edited by Zeld on 01-16-07 01:29 PM) (edited by Zeld on 01-16-07 01:30 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6289 days Last view: 6286 days |
| ||
| Not quite sure what you mean by the "random" thing (from my experience, nothing is ever random...I posted another thread on this board that explained the formula used to generate what everyone used to call random numbers for the Fire Emblem series). I believe a debugger will help there too, but of course, debuggers help everywhere...
I can't find the text in the RAM (usually there's some raw text in the RAM that can be traced to the text in the ROM), so I'm going to have to trace the actual font. :sadpanda: Let me remember what you wanted to change...just text and the introduction scenes, right? Hacking how the characters move around will probably be easier than hacking text, so I'll mess with text first to get the hard part started. Oh, that's what the other stuff was...equipment should be easy as well. New monsters will involve learning how to add every aspect of a sprite's animation, which could be fairly difficult. New missions...I don't know what to think of that. Perhaps making the levels won't be too difficult (though it won't go by quickly), but making the game let you select more missions sounds difficult to me. The whole menu thing... Here's what I have so far: R00=03007e0c - Source R01=0600a000 - Destination (tile data) R02=01000160 - Mode/Size (Fill Mode, 0x160 in size) 08141868 df0c swi $0c The text is decompressed to the IRAM, then copied to the tile data in order to be displayed. What's I've pasted here from my debugger is the location of the copying instruction. Next, I'll set a breakpoint at 3007e0c to find out how the text got there... (edited by Zeld on 01-16-07 05:40 PM) (edited by Zeld on 01-16-07 06:24 PM) |
| Pages: 1 2 3 |
| Acmlm's Board - I3 Archive - - Posts by Zeld |
