Skeetendo

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)

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)

@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)

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 :)

That's what I was talking about here ;)

Last edited by Miksy91 (2014-03-29 09:38:19)

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.

Thanks for the info comet.