You are not logged in.
Pages: 1
Hello All,
I am new to the forum as a member (I've been a lurker here for a few months). I am currently working on a hack that requires a very extended evo/move table.
To this end I need to repoint the table to a new bank. I understand how to edit hex and repoint data and I have a basic understanding of ASM (very basic sadly).
I have been looking at this for several day's and can't for the life of me figure out how to change the bank for the table.
Any help in this would be appreciated.
Edit: Noticed I didn't state the rom base. This is for a Pokemon Gold Rom.
Last edited by BlueMew (2014-03-27 17:44:06)
Offline
This is kinda complicated actually since you can't just do it by changing a byte or two. Besides, the evolution/moveset learning datas are might be accessed in a few different situations, so you would have to find a way to "work it out" somehow.
Anyway, the easiest way to tackle the problem might be moving the "necessary parts" (quite a lot of data actually! 0x300 bytes?) of the routine that handles the evolution/moveset data tables (+ values) to another rom bank (along with all the evolution/moveset data). I have personally done this in my own hack with trainer data. That wasn't as difficult to do as this though because of how the data is "used".
The trainer data is only checked once, and loaded to ram, when the trainer is encountered. In this case when a pokemon gets a level up for instance, we'll have to check all the levels when that pokemon learns a move and not just a byte or two (like the address of the trainer data of that [Trainer Group] + [Trainer No.]) which you could return from another rom bank. No idea if that makes any sense since you haven't been playing around with assembly that much yet.
Edit:
So the problem is this;
Trainer data in another rom bank;
D118 = Trainer Group
D11B = Trainer No.
1. Check the address of the first entry (1st Trainer No.) of this current Trainer Group from a list (= pointer table)
2. Keep incrementing that and everytime we reach byte FF (the trainer data of this current Trainer No. ends), decrement [Trainer No.] value.
3. When Trainer No. reaches 0 we have reached the address of this current [Trainer Group][Trainer No] and we can load the trainer data of this trainer to ram and return.
Now that I think about it, you could indeed do the same with evolution data!
This could be done by (for example) moving the evolution/moveset data of that checked pokemon to address $DF00 ("end of area reserved for stack") and forward.
Now you could return back to rom bank 0x10 and start checking the values in ram, not in rom (where the data is originally stored) like it does right now.
Even so, this is no "piece of cake" job to do.
Last edited by Miksy91 (2014-03-27 20:13:31)
Offline
Things that point to EvosAttacks (Crystal):
Moon Ball
items/item_effects.asm:913: ld hl, EvosAttacksPointers
items/item_effects.asm:916: ld a, BANK(EvosAttacksPointers)
items/item_effects.asm:921: ld a, BANK(EvosAttacks)
items/item_effects.asm:935: ld a, BANK(EvosAttacks)
Egg moves
main.asm:30298: ld hl, EvosAttacksPointers
main.asm:30301: ld a, BANK(EvosAttacksPointers)
main.asm:30304: ld a, BANK(EvosAttacks)
main.asm:30310: ld a, BANK(EvosAttacks)
main.asm:30315: ld a, BANK(EvosAttacks)
Evolution (assumes same bank)
main.asm:47638: ld hl, EvosAttacksPointers
Learning attacks (assumes same bank)
main.asm:48032: ld hl, EvosAttacksPointers
Generating moves for wild Pokemon (assumes same bank)
main.asm:48094: ld hl, EvosAttacksPointers
Checking for pre-evolutions (assumes same bank)
main.asm:48228: ld hl, EvosAttacksPointers
Using evolution stones
main.asm:58199: ld hl, EvosAttacksPointers
main.asm:58219: ld a, BANK(EvosAttacksPointers)
main.asm:58227: ld a, BANK(EvosAttacks)
Last edited by comet (2014-03-27 22:21:17)
Offline
Thanks for the replys guys/gals. I actually noticed the crystal decompilation project a bit after posting this and started looking through it. So now I'm wondering if I went and made all the edits to the "source" evo/move table and then compiled it would it be easier/better then what miksy91 suggested? My hack is still earily stages so I could easily switch to using crystal as a base. I don't want to be disrespectful or discount miksy91's suggestion it just seems more complicated then my current skill set can handle.
Edit: Also what would be a good program to view the graphics in a .pic or .#bpp file from the decompilation projects?
Last edited by BlueMew (2014-03-28 00:32:21)
Offline
@Kumar: I didn't say anyone specifically was a guy/gal. I just happen to know some gals that get offened by being called guys so I've gotten in the habit of saying guys/gals.
Last edited by BlueMew (2014-03-28 01:41:12)
Offline
You would definitely have to do less "adjustments" if you hacked crystal disassembly instead. I wouldn't say it would be that much easier once you're familiar with assembly and looking at hex code in general though, but it has other benefits (like not having to call subroutines in random places and such).
And I'm not offended at all by being called a girl (or "gal", never heard of girls being called that before). own fault for picking up that nickname in the first place. One thing I find a bit silly though is how so many people write that nickname wrong; "hey misky, how about...", but obviously you didn't :)
bluemew wrote:thank you for replies guys/gals
gals!!!
No one above replied is a girl misky is a guy.
That's what I was talking about here ;)
Last edited by Miksy91 (2014-03-29 09:38:19)
Offline
Alright guys thanks for all the help. I think I'm going to go with the crystal disassembly as a base since I can read it easier. (Seeing as its just look at code instead of look at hex, look at asm cheat sheet, write down what the command is, repeat) Hopefully I don't run into to many more snags.
Offline
Edit: Also what would be a good program to view the graphics in a .pic or .#bpp file from the decompilation projects?
Run "make pngs" to convert everything to png. They get converted back automatically when you build. Compression is automatic as well.
If you'd rather work with 2bpp directly, the most functional tile editor is tilemolester.
Offline
Thanks for the info comet.
Offline
Alright guys thanks for all the help. I think I'm going to go with the crystal disassembly as a base since I can read it easier. (Seeing as its just look at code instead of look at hex, look at asm cheat sheet, write down what the command is, repeat) Hopefully I don't run into to many more snags.
We have "hex editors" that are specialized into GB/C asm hacking too :)
(You can view the hex code of the game, but that is also represented in symbolic GB/C cpu language.)
But yeah, disassembly is more simple than working out with editors.
Offline
Pages: 1