Research: Hacking Evolutions

[redriders180]

Before I say anything: Hi there! I'm fairly new here, but I've been pondering a question for a while. How can we give Pokemon new evolutions?

The Problem
I've tried to use many programs to make new ways of evolution. These programs usually are very limited, allowing you to only create evolutions within certain parameters, i.e. By level up, using a stone, trading, trading with a specific item, basically, any way that a Pokemon can evolve up to Generation III. What I want to do is to make more ways of evolution, if this is possible.

Investigating
Of course, we can't try to figure out EVERY way to evolve...there is too many. We can suggest more as we go, But I'd like to start of with these, which are ways Gen IV Pokemon evolve:

• Evolving by level up, holding an item
• Evolving by certain locations
• Evolving with a certain Pokemon in the party
• Evolving by items other than Water, Thunder, Fire, Leaf, or Sun Stone.

Other ideas, which no current Pokemon evolve by, but someone might want to try:

• Evolving with certain stats maxed out (Cool, Smart, etc...)
• Evolving with a stat in relation to another stat (Like Tyrogue).
• Evolving with no happiness

The list is long, as I've said before. I don't know anything specific about evolution data, But I will be willing to learn anything I can to try it out. I have mostly XSE knowledge, but I am going to try ASM soon.

Thank you for reading, and thanks for your help! I'm sorry if this has been covered in other topics, but I couldn't find one specifically. If you do know of someone else who has covered this, if you could PM it to me, I'd really appreciate it.

PS: The hack I am using is FireRed, but I think it might be good if we covered the many different Gen III games. I'm not sure what else to say. Thanks again :3

[Darthatron]

Something like this is surprisingly easy to do. You just branch an ASM routine from the current evolution routine and expand the switch statement to include more than the original evolutions.

According to my notes, the evolution routine is at 0x080CE8DC in FireRed.

[Team Fail]

It would be certainly interesting, but tools would have to be expanded for the almost-limitless possibilities for evolution. Well, unless you're in for a ton of Hex Editing. But yes, I do think it would just be expansion of the evolution method table, as Darthatron mentioned, and some ASM routines to allow for them.

[redriders180]

I'm sorry for asking, but would it be too much trouble to ask for an example? I am new to ASM (So new that I know next to nothing), and don't want to mess my game up too badly (even with a backup).

Edit: Forgot to say thanks :3

[Team Fail]

Originally Posted by redriders180

I'm sorry for asking, but would it be too much trouble to ask for an example? I am new to ASM (So new that I know next to nothing), and don't want to mess my game up too badly (even with a backup).

Edit: Forgot to say thanks :3

It can be as simple as checking a player's Secret ID or as advanced as a puzzle that uses controls graphics and sprites, as well as integrated music.

Or checking stats.

[Late]

Jambo51 made all evolution types from Gen IV and V available in FireRed. Maybe he can help you.

[Jambo51]

You are correct, sir! I have indeed made all the new official evo types work. The best thing is, we could easily come up with our own complicated evo types if we wanted to. I'll post/edit this post a short explanation of how to add new evo types (stones included) when I get home from work.

[Fireworks]

Originally Posted by Jambo51

You are correct, sir! I have indeed made all the new official evo types work. The bedt thing is, we could easily come up with our own complicated evo types if we wanted to. I'll post/edit this post a short ecplanation of how to add new evo types (stones included) when I get home from work.

Please tell me they work for Ruby?

[Jambo51]

They do not work for Ruby. I'm not a Ruby hacker, so I won't be the one to port them over to Ruby. I hack Fire Red (mainly) and a little Emerald.

Tell me, why do people still insist on hacking Ruby?
Emerald is the same, but better! XD

PREPARE FOR WALL OF TEXT, DON'T SAY I DIDN'T WARN YOU!

Anyway, here's a quick explanation of how the evo routine works:
First of all, it gets the species of the Pokémon who's evolution is being checked, then reads the relevant slot(s) on the evolution table (0x25977C), and checks what type of evolution it is.

It reads the first half word (although it's only ever a byte as there aren't that many evo types), and then subtracts 1 from the number. It then reads a table, which is located at 0x42FC4 (NOTE: BPRE 1.0 only), and gets the relevant routine to call from this table. It then executes the checks required for the evolution using various asm processes. I can't be too specific here, as each one is VASTLY different dependant on the evolution requirements.

Anyway, it reads the requirements from the evolution table, and checks if the Pokémon meets these requirements. If so, it stores the species to evolve to, then moves on to check the rest of the Pokémon in the party.

Each evolution "method" (Called on level up, Called on trade, and called on item use) uses a slightly different routine to run the checks.

The called on level up is the most common, and easiest understood. It starts at 0x42EC4. All it does is run through the Pokémon's evo data, and reads the evo types stored there. It then goes to the relevant routine (by the method described above), and executes the relevant checks for that evo type.

Then it loops back round to check the rest of the evo types for that Pokémon.

The items (aka Evolution stones) are only called upon you pressing "Use" on an evolution stone. It starts at 0x43182. It runs through your party checking all their evolution data for a match of the item you have used. If it can't find a match, it shows the message "Can't use" (or whatever it is), if it CAN evolve, it shows the HP bar instead.

Upon selecting a Pokémon with the item, the game runs a second check, using the same routine, to see if the one you selected can or can't evolve using that stone, and either prints the message saying it won't work, or evolves the Pokémon.

It's easy enough to make the game run this check to support new stones, but they still won't work. There's a table in the rom (which I have sadly long since lost the location of) which the game reads for behaviour upon selecting a Pokémon. When this table is updated to contain the correct behaviour, the new stones work a treat. The Dawn Stone is a special exception, and actually requires a rewrite of the routine to support the gender specific attributes it has.

Finally, the most complicated is trading. The routine for this begins at 0x43122 (I think...). It's largely unused in ROM hacks, but that won't stop me divulging its secrets!
This is only called after the completion of a trade.

It runs the checks in a similar-ish manner to the level up one. It checks the TRADED Pokémon only to see if it has a trade evolution. It simply branches off to the relevant routine here, as there are only 2 existing options (type 05 and 06). Type 05 simply evolves straight away, while 06 checks for the relevant item first.

So, now that the explanation of its workings is over, i'm sure you would like to know what that actually achieves?
Well, if you paid attention, you'll notice I GAVE you the locations you need to look at to find everything!
Good luck! I'll post my routines/findings tomorrow, but for now... Bed Time! :D

[metapod23]

Originally Posted by Jambo51

They do not work for Ruby. I'm not a Ruby hacker, so I won't be the one to port them over to Ruby. I hack Fire Red (mainly) and a little Emerald.

Tell me, why do people still insist on hacking Ruby?
Emerald is the same, but better! XD

PREPARE FOR WALL OF TEXT, DON'T SAY I DIDN'T WARN YOU!

Anyway, here's a quick explanation of how the evo routine works:
First of all, it gets the species of the Pokémon who's evolution is being checked, then reads the relevant slot(s) on the evolution table (0x25977C), and checks what type of evolution it is.

It reads the first half word (although it's only ever a byte as there aren't that many evo types), and then subtracts 1 from the number. It then reads a table, which is located at 0x42FC4 (NOTE: BPRE 1.0 only), and gets the relevant routine to call from this table. It then executes the checks required for the evolution using various asm processes. I can't be too specific here, as each one is VASTLY different dependant on the evolution requirements.

Anyway, it reads the requirements from the evolution table, and checks if the Pokémon meets these requirements. If so, it stores the species to evolve to, then moves on to check the rest of the Pokémon in the party.

Each evolution "method" (Called on level up, Called on trade, and called on item use) uses a slightly different routine to run the checks.

The called on level up is the most common, and easiest understood. It starts at 0x42EC4. All it does is run through the Pokémon's evo data, and reads the evo types stored there. It then goes to the relevant routine (by the method described above), and executes the relevant checks for that evo type.

Then it loops back round to check the rest of the evo types for that Pokémon.

The items (aka Evolution stones) are only called upon you pressing "Use" on an evolution stone. It starts at 0x43182. It runs through your party checking all their evolution data for a match of the item you have used. If it can't find a match, it shows the message "Can't use" (or whatever it is), if it CAN evolve, it shows the HP bar instead.

Upon selecting a Pokémon with the item, the game runs a second check, using the same routine, to see if the one you selected can or can't evolve using that stone, and either prints the message saying it won't work, or evolves the Pokémon.

It's easy enough to make the game run this check to support new stones, but they still won't work. There's a table in the rom (which I have sadly long since lost the location of) which the game reads for behaviour upon selecting a Pokémon. When this table is updated to contain the correct behaviour, the new stones work a treat. The Dawn Stone is a special exception, and actually requires a rewrite of the routine to support the gender specific attributes it has.

Finally, the most complicated is trading. The routine for this begins at 0x43122 (I think...). It's largely unused in ROM hacks, but that won't stop me divulging its secrets!
This is only called after the completion of a trade.

It runs the checks in a similar-ish manner to the level up one. It checks the TRADED Pokémon only to see if it has a trade evolution. It simply branches off to the relevant routine here, as there are only 2 existing options (type 05 and 06). Type 05 simply evolves straight away, while 06 checks for the relevant item first.

So, now that the explanation of its workings is over, i'm sure you would like to know what that actually achieves?
Well, if you paid attention, you'll notice I GAVE you the locations you need to look at to find everything!
Good luck! I'll post my routines/findings tomorrow, but for now... Bed Time! :D

I was just wondering if a routine could be made using this info to make a Pokemon evolve at any time outside of battle? How hard/easy would that be to do, if you store the Pokemon position and/or species in a variable and then called the routine to evolve that particular Pokemon?

Thanks to anyone for any insight.

[TheDarkShark]

I'm not sure, but I think you could run one of the check routines already used in the game. I don't really think that would work without slightly customizing the routine so it checks for the correct pokémon, though...
But wait, I think you want an unconditional evolution which is always caused when the script runs, right? Err, I think that'd be a bit harder. You'd need to analyse the checking routines to get the routines that make the pokemon evolve. Then write a routine that loads some variables (e.g. the pokemon's party slot, I guess? I don't know, but I'm pretty sure that you'll need it to run the evolution routine.) and calls the evolution routine.

That's just an idea, though. To be honest, I haven't looked at the routines ><

[Jambo51]

Actually, you're very close to having a good answer here. If we can call the evolution checking routine, we could easily evolve from any script. And forcing evolution is as easy as ignoring the evolution conditions. What i'm talking about is directly calling the actual evolution routine, passing it values read from variables, to force evolution of a given pokemon. If I could find the actual routine which executes evolution, I could easily produce a routine for you to call.

[metapod23]

Originally Posted by Jambo51

Actually, you're very close to having a good answer here. If we can call the evolution checking routine, we could easily evolve from any script. And forcing evolution is as easy as ignoring the evolution conditions. What i'm talking about is directly calling the actual evolution routine, passing it values read from variables, to force evolution of a given pokemon. If I could find the actual routine which executes evolution, I could easily produce a routine for you to call.

Shouldn't the offsets you posted eventually call the evolution routine? I would look for it, but I don't know how to decompile in-game routines properly.

[TheDarkShark]

Well, if you can't get IDA Pro to work properly on your PC (like me on my laptop - now that I'm on my PC again I'd better try again...) you could use VBA-SDL-H. That's the debugging version of the VBA. Simply press F11 to get to the debugger and type dt <Thumb Routine Offset> to disassemble the routine. Doing it that way you can only view 20 opcodes at once plus you can't simply save the routine to a file, afaik.
Here's a link to a German website where you can download an old version of IDA for free. I don't have a link to an English page, sorry.
http://www.chip.de/downloads/IDA-Pro..._29744270.html

You can get the VBA-SDL-H at the official VBA page or, for example, in HackMew's ASM-Tutorial.
Even if that's a bit off-topic, I hope it helped...

[sky_queen3]

Wait, so they've figured out how to add new evolution stones? :cer_love:
Awesome!

[Jambo51]

Originally Posted by metapod23

Shouldn't the offsets you posted eventually call the evolution routine? I would look for it, but I don't know how to decompile in-game routines properly.

No, no, these routines call the CHECKING routine. You want to bypass this altogether and call the actual evolution routine, and force the evolution (presumably of Charmander/Charmeleon) into its next stage, ignoring the level requirement.

Am I correct, sir?

If so, a small custom routine to detect from a variable what Pokémon ID to evolve would be all that would be required, then directly call the evolution routine if said Pokémon is in your party.

[TheDarkShark]

Just a suggestion to make: What about having the pokemon species to evolve in one variable, the species to evolve it to in another? If the original routine takes the evo-slot of the species as a parameter instead of the species it might be hard, though...
Oh, and what about a safety check, just in case you have two pokemon of the same species? For my personal needs, I'd like to have the party slot as an additional parameter.
Anyways, gotta do some research for the code hack I'm currently working on myself. See ya'

[JPAN]

I've been trying to make it work, because of the Experience adding method on the Hacked engine, but all the results I had so far are disappointing.
There are two routines that perform evolution that I checked: the Bag-to-bag Evolution routine and the BattleScreen-to-Overworld routine. Haven't looked at the trade one yet.

At 0x08015AAE starts a loop that checks for all pokemon involved in battle, if any changed in a way that causes evolution, and evolves them if it's true. 0x08015AD2 contains the call to the Evolution checker, and at 0x08015AE0 there is a placing of 0x08015B30 to further execution at the function stack, as well as a call to 0x080CDDF4, the only place where all checked Show Evolution methods converge.

At 0x080CDDA8 starts the bag-to-bag evolution display. Loads the first function to use on screen, and deals with the rest later.
This function receives r1 as the pokemon to evolve to, r2 as a status flag, where bit 1 is canCancel, and R3 is the slot of the pokemon to evolve.
So, if you had r1 = 7, r2=1, r3 = 0 , you would be presented with a screen of your party leader evolving into squirtle. R0, from code examples, was the address for the pokemon, but bad coding erase it before it's used.

Now, these functions graphic nature make them only work properly on the exact moment they should be used. So, if you try to call them from, say, a script, you get a eternal black screen after the evolution.

I even tried to replace the "outer shell" of calls of this function for one that is script-ready (special 0xc2, hatching animation), but had no sucess. Maybe due to the also complex nature of the hatch animation.

So, can we evolve pokemon as we want? yes. Can we call it when we want? not yet. Only if using a party item (such as stones), or right after battle.

PS: While the current Item system allows you to create new Stones easily(See my Items thread last post for more), it is so limited that the only way to create an item that evolves pokemon to a specific species all the time (like a special berry that evolves all fish pokemon to Gyarados) would need to alter the Stone Evolution code.

[metapod23]

Originally Posted by Jambo51

No, no, these routines call the CHECKING routine. You want to bypass this altogether and call the actual evolution routine, and force the evolution (presumably of Charmander/Charmeleon) into its next stage, ignoring the level requirement.

Am I correct, sir?

If so, a small custom routine to detect from a variable what Pokémon ID to evolve would be all that would be required, then directly call the evolution routine if said Pokémon is in your party.

Yes, that's correct.

Originally Posted by JPAN

I've been trying to make it work, because of the Experience adding method on the Hacked engine, but all the results I had so far are disappointing.
There are two routines that perform evolution that I checked: the Bag-to-bag Evolution routine and the BattleScreen-to-Overworld routine. Haven't looked at the trade one yet.

At 0x08015AAE starts a loop that checks for all pokemon involved in battle, if any changed in a way that causes evolution, and evolves them if it's true. 0x08015AD2 contains the call to the Evolution checker, and at 0x08015AE0 there is a placing of 0x08015B30 to further execution at the function stack, as well as a call to 0x080CDDF4, the only place where all checked Show Evolution methods converge.

At 0x080CDDA8 starts the bag-to-bag evolution display. Loads the first function to use on screen, and deals with the rest later.
This function receives r1 as the pokemon to evolve to, r2 as a status flag, where bit 1 is canCancel, and R3 is the slot of the pokemon to evolve.
So, if you had r1 = 7, r2=1, r3 = 0 , you would be presented with a screen of your party leader evolving into squirtle. R0, from code examples, was the address for the pokemon, but bad coding erase it before it's used.

Now, these functions graphic nature make them only work properly on the exact moment they should be used. So, if you try to call them from, say, a script, you get a eternal black screen after the evolution.

I even tried to replace the "outer shell" of calls of this function for one that is script-ready (special 0xc2, hatching animation), but had no sucess. Maybe due to the also complex nature of the hatch animation.

So, can we evolve pokemon as we want? yes. Can we call it when we want? not yet. Only if using a party item (such as stones), or right after battle.

PS: While the current Item system allows you to create new Stones easily(See my Items thread last post for more), it is so limited that the only way to create an item that evolves pokemon to a specific species all the time (like a special berry that evolves all fish pokemon to Gyarados) would need to alter the Stone Evolution code.

Thank you for looking into it, JPAN. I appreciate the effort.