(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
04-29-24 01:23 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - FE 7 Assembly Hack New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
Zeld

Red Paragoomba








Since: 11-05-06

Last post: 6283 days
Last view: 6280 days
Posted on 12-03-06 01:59 AM Link | Quote
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)
Jigglysaint

Octoballoon








Since: 11-19-05

Last post: 6299 days
Last view: 6284 days
Posted on 12-03-06 10:29 PM Link | Quote
What does FE stand for exactly?
Zeld

Red Paragoomba








Since: 11-05-06

Last post: 6283 days
Last view: 6280 days
Posted on 12-03-06 10:34 PM Link | Quote
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.
labmaster

Red Paragoomba


 





Since: 11-18-05
From: Away for exams, back mid-December.

Last post: 6355 days
Last view: 6285 days
Posted on 12-03-06 10:48 PM Link | Quote
Nice work - my only suggestion would be to move all of your pc relative literals into a pool at the end of the routine (from memory the range of an ldr is almost a kilobyte) so you don't have to have all of those branches jumping over them in the middle of your code.


(edited by labmaster on 12-03-06 09:51 PM)
Zeld

Red Paragoomba








Since: 11-05-06

Last post: 6283 days
Last view: 6280 days
Posted on 12-04-06 12:08 AM Link | Quote
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)
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6280 days
Last view: 6280 days
Posted on 12-04-06 06:18 PM Link | Quote
You can attatch files to posts.

Also I can understand it being fun to just give your character Godlike powers. OoT was fun the first few times but now it's kinda meh. Being able to fly, outrun Sonic the Hedgehog, grab anything with a hookshot from any distance, kill anything with one hit while never taking any damage yourself, etc does add a bit of fun back into the game.
Zeld

Red Paragoomba








Since: 11-05-06

Last post: 6283 days
Last view: 6280 days
Posted on 12-04-06 07:20 PM Link | Quote
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?...

Attachments

labmaster

Red Paragoomba


 





Since: 11-18-05
From: Away for exams, back mid-December.

Last post: 6355 days
Last view: 6285 days
Posted on 12-05-06 12:33 AM Link | Quote
You haven't been hand-assembling those, I hope?

If so, Goldroad is your new friend.

Okay, as for the permanent-gameshark-code question. It sounds like you've got an address that you want to freeze to a certain value (or at least change), but it gets re-written more often than the gameshark triggers? If so, you'll either want to change the assembly that writes that particular value, or, change the game's master code to hook that routine, so that whenever the value gets written, the gameshark's code handler is run, and overwrites it straight away.
HyperHacker

Star Mario
Finally being paid to code in VB! If only I still enjoyed that. <_<
Wii #7182 6487 4198 1828


 





Since: 11-18-05
From: Canada, w00t!
My computer's specs, if anyone gives a damn.
STOP TRUNCATING THIS >8^(

Last post: 6280 days
Last view: 6280 days
Posted on 12-05-06 03:13 AM Link | Quote
Embedding Gameshark codes into a game depends on the type of code, but it's not generally that difficult. Basically hook the VBlank handler and do whatever that code would be doing, just as the Shark itself does.

I just made and posted the Hookshot code in ROM Hacking a day or two ago, so no surprise you haven't heard of it.
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6279 days
Last view: 6279 days
Posted on 12-05-06 04:25 AM Link | Quote
Labmaster: just curious, would that "goldroad" be suitable for homebrewing DS software as well? The architechture of the ARM9 is no different from the ARM7, to my knowledge, but designating which code goes with which processor might be an obstacle, I'm thinking. I haven't tried the assembler myself just yet.
Zeld

Red Paragoomba








Since: 11-05-06

Last post: 6283 days
Last view: 6280 days
Posted on 12-05-06 01:42 PM Link | Quote
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)
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - FE 7 Assembly Hack |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.018 seconds; used 412.88 kB (max 518.39 kB)