Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Rom Hacking: hukka | 2 guests
Acmlm's Board - I2 Archive - Rom Hacking - Zelda 2 hacking | |
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
Deathknight

Blue Octorok
Level: 11

Posts: 1/46
EXP: 5270
For next: 715

Since: 01-21-05

Since last post: 63 days
Last activity: 113 days
Posted on 01-21-05 05:06 AM Link | Quote
Hey, I'm currently finishing X-4000s rom hack Zelda 2 Challenge: The Shadow of Link and was wondering if someone could help me out with something. I am interested in changing the point values and the number of hit points enemies have and I can't seem to figure out a way to do it. Also, I want to change the locations of the battle spots and don't know how. Anyone know how I could go about doing any of this?
Parasyte

Bullet Bill
Level: 35

Posts: 216/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 01-21-05 06:08 AM Link | Quote
Hacking the hit points for enemies is trivial. The easiest way to go about it is using a cheat search (FCEUXD) to find the address in RAM which holds any given enemy's hit points. Finding this value is usually done with less than/equal to last searches after hitting a single enemy (or not, as the case may be). Through process of elimination, you will arrive at that enemy's hit point variable. After finding that, you must use write breakpoints on that address to determine what value is written (the initial hit point value for said enemy) and backtrace some assembly to find where that value comes from.
If you are unfamiliar with cheat searches or assembly, then it may be difficult to find. But after you become accustomed to both, finding data like that is an easy matter... Usually.

For your other questions, I do not quite understand. I don't play Zelda 2 much, because I really dislike the game.
If the "battle locations" are static places on the overworld, you may be able to find that data using overworld coordinates. Find the coordinates in a cheat search, of course. Then watch how the game uses them (read breakpoints) when you pass over certain locations. With a static "battle location" the game must either read those coordinate to decide if it should start a battle. So it's definitely a good starting point.
Deathknight

Blue Octorok
Level: 11

Posts: 2/46
EXP: 5270
For next: 715

Since: 01-21-05

Since last post: 63 days
Last activity: 113 days
Posted on 01-21-05 07:34 AM Link | Quote
Alright, how would I run a cheat search? Any programs that could help me with this that you would recommend? I've already got a few hex editing tools but I don't know if they'll help. I'm new to this kind of thing and have been doing most of the editing using the Zelda 2 editor that was released some time back and even that has a few flaws in it. Anyway, thanks.
Ice Ranger

Leever
Level: 23

Posts: 59/183
EXP: 60462
For next: 7261

Since: 03-16-04

Since last post: 82 days
Last activity: 3 days
Posted on 01-21-05 07:49 AM Link | Quote
Originally posted by Parasyte
The easiest way to go about it is using a cheat search (FCEUXD) to find the address in RAM which holds any given enemy's hit points.


Got the link to FCEUXD here. Not the source code. The other one. You should be able to figure it out pretty quick whenever you look at it. Do something, click a button according to what you're looking for. Do something else, click a button according to it again. ... about 5 to 20 times later, you should have 10 or so cheats to look through. That's all I can help you with (as simple as it sounds. Hey, at least I posted the link ).

_edit_
Look at Parasyte's documents for help using the cheat search. It's what I used to figure it out. There's three to look at, maybe it'll help you figure it out.


(edited by Chill Penguin on 01-20-05 11:01 PM)
Deathknight

Blue Octorok
Level: 11

Posts: 3/46
EXP: 5270
For next: 715

Since: 01-21-05

Since last post: 63 days
Last activity: 113 days
Posted on 01-21-05 08:15 AM Link | Quote
Alright, I've got it opened and the cheat search comes up with like over 10,000 search results. How do I get fewer results and how do I test the values to know I have the right one when I've found it.
Parasyte

Bullet Bill
Level: 35

Posts: 217/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 01-21-05 08:41 AM Link | Quote
After pressing the "Reset" button, you've saved a "snapshot" of all current values in RAM. This is not enough to find what you need. So after the Reset button, close the cheat window and get back to the game. Then forcibly change what you are attempting to search. For example, if you're searching for the enemy hit points, damage an enemy! This will cause that enemy to lose hit points.
After making your "forced change" you can go back to the cheat window, and push the "Less Than" button. This will grab another snapshot of values in RAM, and compare them with the LAST snapshot. The Less Than button will specifically record only values that are currently LESS THAN the values from the last snap shot. By continuing with this process of elimination (and mixing searches with "Equal To" when you do not attack the enemy) you will begin to get less and less possible codes. If you've done your comparative searches properly, then you will be left with very few possible RAM addresses after a few successive searches. I usually find that I end up with about 1-3 possibilities after about 3 searches. But it can really vary depending on how and what you are searching.

To verify that a possibility is the right address, select it in the list box, and the Address and Value boxes will be filled in in the left-hand pane. After that you just click the "Add" button at the bottom, and the cheat will be added. You can then get back to the game and attack the enemy. If the enemy never dies, you have certainly found the proper variable. (The cheat search "freezes" the RAM address with a certain value. Which should make enemies take unlimited hits without dying.)
bbitmaster

Koopa
Level: 18

Posts: 64/103
EXP: 25264
For next: 4633

Since: 03-28-04
From: Knoxville, tTN

Since last post: 12 days
Last activity: 7 days
Posted on 01-21-05 09:06 AM Link | Quote
I wrote a document on this very subject, which you can find here:
http://fceuxd.infinihost.net/EnemyHealth.txt
Deathknight

Blue Octorok
Level: 11

Posts: 4/46
EXP: 5270
For next: 715

Since: 01-21-05

Since last post: 63 days
Last activity: 113 days
Posted on 01-21-05 11:51 AM Link | Quote
Alright, I managed to get the hitpoint value for an enemy as a test but when I put into a break point nothing happens. It says it's supposed to jump at a line but it doesn't move at all.
Parasyte

Bullet Bill
Level: 35

Posts: 218/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 01-21-05 06:07 PM Link | Quote
You must make sure that the "Write" checkbox is checked, so that the debugger knows to watch for writes to the address. Any time that the game makes a change to that address, the debugger will snap (pause the game and take you to the instruction which is writing to your break address).
Deathknight

Blue Octorok
Level: 11

Posts: 6/46
EXP: 5270
For next: 715

Since: 01-21-05

Since last post: 63 days
Last activity: 113 days
Posted on 01-21-05 08:56 PM Link | Quote
Well, that sort of worked except for one problem. It gave me the hex value of the enemy's location rather than their hp.
Parasyte

Bullet Bill
Level: 35

Posts: 220/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 01-21-05 09:00 PM Link | Quote
Yes, this is where assembly programming/hacking skills come in handy! It's not exactly a straight-forward thing to find or edit. It would probably be best if someone wrote a tutorial for this specific game. Then you could follow along and learn a bit about what's actually going on.

I'll spend a few moments on it this after noon, after my classes are over.
Deathknight

Blue Octorok
Level: 11

Posts: 7/46
EXP: 5270
For next: 715

Since: 01-21-05

Since last post: 63 days
Last activity: 113 days
Posted on 01-21-05 09:04 PM Link | Quote
Yeah, if you want the value I was using it was 00C5 and it was for blue gels in the overworld (just hit a weak enemy on grass.) I wish there was a guide, I wasn't able to find one.
Edit: Upon closer analysis I've noticed that it doesn't give me the point in the ram where it changes. When I try to read that line it says it's undefined and skips it. Interesting.
Edit 2: Alright after a lot of frustration, I finally am finding values the problem is that I have no way to control what the value is. There is no way to predict what values each hex value will bring.


(edited by Deathknight on 01-21-05 12:09 PM)
(edited by Deathknight on 01-21-05 03:04 PM)
(edited by Deathknight on 01-22-05 01:01 AM)
Reshaper256

Bee
Level: 19

Posts: 104/143
EXP: 34776
For next: 1001

Since: 09-14-04
From: United States

Since last post: 5 days
Last activity: 9 hours
Posted on 01-26-05 03:35 AM Link | Quote
Hey Deathknight, I've been looking at your situation, and this is what i have so far:

I set a write break-point on the value $00C5 (The health of some of some slimes.) At first I just hit the slime, to take it's damage down and change it's health, but that didn't help me find the value for the slime's 'original health'.

When I entered another battle from the overworld, the debugger snapped on the break-point twice - first it loaded #$00 from the Accumulator (let's just call it A), and the second time it loaded #$03 from A, the 'original health' of the slime. After that the fight was loaded.

I set the trace logger to see what the instruction just before the second time the debugger snapped on the break-point had been and it said that #$03 had been loaded into A from $6D25. (Now i realize I could have just scrolled the debugger up to find this out.)

I put a write break-point on $6D25, and it didn't snap the debugger until I actually reset the game and hit start on the name selection screen. Value #$03 had been loaded from A, so I used the trace logger again to find the instruction that put #$03 into A to start with. (Again, I could have just scrolled up the debugger a little to find that out, but hey, I'm stupid.)

Value #$03 was loaded into A from $9425, and FCEUXD will tell you that's $5435 in the ROM itself. Change that value, and it changes the value of (some) slimes' health to that. I haven't looked into why all the slimes' health aren't controlled by a single address, but the other addresses could probably be found the same way this one was.

To sum it up...

$5435 in the Zelda II ROM = $9425 in NES Memory while this happens.
$9425 contains #$03, which is loaded into the Accumulator when you hit start at the File Select screen...
...then instantly #$03 is loaded into $6D25 (NES Memory), from the Accumulator.
When the battle loads that has the slimes:
#$03 is loaded into the Accumulator from $6D25...
...then instantly #$03 is loaded into $00C5 from the Accumulator.

Hope I've helped you out here.


(edited by Reshaper256 on 01-25-05 06:52 PM)
(edited by Reshaper256 on 01-25-05 06:53 PM)
(edited by Reshaper256 on 01-25-05 08:56 PM)
Euclid

Cheep-cheep
Level: 23

Posts: 131/193
EXP: 65528
For next: 2195

Since: 03-15-04
From: Australia

Since last post: 24 days
Last activity: 7 days
Posted on 01-26-05 05:14 AM Link | Quote
As i have told DeathKnight already.

Experience is shared (since there's only 16 set of exp), and the palette data is with it as well (the higher 8 bits), 54EA is for the red gel i think.

As for the health, it's not shared since red gels != blue gels since they use a different palette, health is also 8 bits so it doens't get bigger than 255.

btw don't use fceud, use fceuXD =P
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Rom Hacking - Zelda 2 hacking | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.026 seconds.