Making a script behavior byte

Unfortunately I'm not 1337 enough to completely create a new behavior byte, so this will show you how to modify the behavior byte that displays the questionnaire in order to make it run a script.

This is for FireRed US version.

Remember, ALWAYS back up your ROM before doing these types of edits, because if a mistake is made, bad problems could pop up.

Tools needed:

• Hex editor(I use Hex Workshop, google it)
• AdvanceMap(To set the behavior byte to tiles)
• VBA(or any other emulator. If you don't have an emulator you probably shouldn't be hacking)
• XSE (Optional, but will make text insertion much simpler)

First, you need to go to the offset of behavior byte 8F (the byte we'll be changing) in a hex editor. Because I'm not sure what the function of some of the bytes are I can't determine the exact starting position of the data, but the beginning portions don't matter with this method. Go to offset 1A7707. This is a pointer for text to display before the script runs.



Now, either write down 1A7707 somewhere, or just refer back here later. You're going to want to modify this text. Find a free offset with Free Space Finder, you don't need many bytes. 100 will probably be more than enough. Now come up with some text that can be displayed before your script executes. (I couldn't find a way to just get rid of this text box, so be creative) Go to the free offset you just got.



Ignore this next portion if you want to do things the easy way. Open your ROM in XSE and create a dynamic script in this format:


Now compile that script, and use the offset it was compiled to for your text pointer.

Now you're going to need to translate your text into hex, if you didn't use the easy XSE method. Here's a table of translations:

Make sure your text code ends in an FF byte. Now, find the offset of where your text starts. You're going to need to flip the order around. For example, if the offset was 123456, you'd use 563412. Now return to offset 1A7707. There are 3 bytes here, followed by a 08 byte. This is the pointer to the text. Replace the 3 bytes before the 08 with the offset you just wrote your text to, in flipped order as I mentioned earlier. If you were to save and test now, your inserted text would be displayed, then you'd see a yes/no box and the questionnaire.

Now, you're not going to want that yes/no box there. Look after the pointer, there's a 09 byte and a 05 byte. Don't touch the 09. The 05 is the type of message, which is indicating it as a yes/no message. Replace the 05 with either 04 or 06, it doesn't matter which. I use 04 because it looks just a tiny bit nicer, since the box won't close between that text and your script, but if your script doesn't immediately have another text box, use 06.

Now, there are 2 more pointers to edit. One is for if you said yes, one is for no, but without a yes/no choice we want the script to run no matter what, and strangely without the yes/no it alternates every other time. They look the same as the other, 3 bytes followed by a 08. The first is at 1A7714, the second is at 1A771E. Now take the offset of whatever script you're writing to the behavior byte and flip it like you did with the offset of your text earlier. Insert those 3 bytes over the old 3, and leave the 08. (as well as everything else around) Do this for both pointers.

(The image isn't cut off at the right, that's the end of the line, that pointer has 2 bytes on one line and one on the next)

Now, save your ROM and open it up in VBA, and go interact with a tile with the behavior byte 8F (set in AdvanceMap's tile editor; by default the questionnaire pad in the pokemart has this byte) If you did everything properly, your script will run on this tile without any script placed on it. Congratulations, you just made a behavior byte of your script!

Note that the yes/no box above is part of my script, the one stored in the behavior byte is eliminated. Before this box, it displays the text "A POKéMON could be in this tree.", which is what I wrote to the byte's text display, then it compares the move headbutt and if no Pokemon knows it, the script just ends there without showing more text. You need to be a bit creative to make the script byte run seamlessly.

This should be helpful, but a couple of things.

First, how do I find the general area for the particular behavior byte? I want to change the Surfing behavior byte.

Second, I suppose you could just use XSE to write the script you want spoken rather than doing hex editing, right? Like:

#org @start
= Would you like to use headbutt?

Wouldn't that work, and then write down the offset for the behavior byte to point to?

Third, I didn't write the hex translations table, so I don't deserve the credit.

This will be really helpful for me if I can ever figure out where the behavior bytes I want to edit are located.

metapod23 said:

This should be helpful, but a couple of things.

First, how do I find the general area for the particular behavior byte? I want to change the Surfing behavior byte.

Second, I suppose you could just use XSE to write the script you want spoken rather than doing hex editing, right? Like:

#org @start
= Would you like to use headbutt?

Wouldn't that work, and then write down the offset for the behavior byte to point to?

Third, I didn't write the hex translations table, so I don't deserve the credit.

This will be really helpful for me if I can ever figure out where the behavior bytes I want to edit are located.

Click to expand...

Yes, but if someone has lots of HEADBUTT trees, making all those scripts in A-Map can really be boring.

Now I have a question, if we use JPAN's hacked FR engine, couldn't we just add more behaviour bytes than editing them?

Full Metal said:

@shiny bill-um wow...fail. did you even read the tutorial, or metapods question?What he(she) was asking was if you could use xse to compile the text for you, and then just point to that, rather than use a hex editor to do the text editing. And to answer your question metapod, yes you may as well just use a dynamic in XSE and compile some text...

Click to expand...

Really wow, my bad. Thought he was trying to say compile one script and assign it to every tree he wanted. Sorry 'bout that.

I don't know if you could use JPAN's engine or not, my ROM doesn't use it and I'm not about to try patching it to an already-hacked ROM.

To find the location of the byte, what I did was I took the text from the questionnaire (There is a questionnaire. Fill it out?) And translated part of that to hex, then searched for it, then got the offset of that text and searched for a pointer to it. Finding out how the script pointers worked was trial and error, I noticed they used standard scripts when I decompiled one of the offsets that's pointed to for the hex viewer and noticed it was a fully functional script.

And yes, you certainly could use XSE to compile the text. I just prefer writing it out in hex for some reason. I'll go add that to my tutorial, as it'd be a lot easier.

I'm going to go look around the hex code later and see if I can find the beginning of the table of behavior bytes and its pointer. Then if I can figure out the normal behavior byte format, it shouldn't be hard to repoint the table and add new behavior bytes.

@metapod23: I went searching through the hex code for the text "The water is" and found the phrase "The water is dyed", which I expected to be the beginning of the text used for the Surf byte. However, there were no pointers to this offset. So it looks like the Surf byte is stored a bit differently.

@PeregrineFig, the text you found is a remnant of the R/S text. If you look alongside it, you'll find DIVE text as well. The actual text is farther into the ROM.

diegoisawesome said:

@PeregrineFig, the text you found is a remnant of the R/S text. If you look alongside it, you'll find DIVE text as well. The actual text is farther into the ROM.

Click to expand...

Ahh, I totally forgot what the text for surfing in FR was. I actually had to play my cartridge to figure it out :nervous:

metapod, the pointer for the Surf byte's text is at 001A6AEF. It appears to be largely stored the same way as the 8F behavior byte, however, as you might expect, Surf isn't done with a regular script. None of the surf pointers lead to standard XSE scripts, so you'll have to decipher the hex/ASM yourself to edit that.

Thanks for the help everyone. I did some testing and it looks like it's the second byte that causes the surf animation, not the first one. So it would be the 04. So I presume since I can't alter the behavior for 04 in XSE, that i could alter another bite that I can find and put that in instead of 04? I'm just not sure which bite to alter or how to locate it. I guess I could use 8F, since that's what the tutorial suggests. I just wish I knew what they all did ...

EDIT: No, that doesn't seem to work after all.

Oh, and I found the offset for the questionnaire script - it's 0x1A6AC0. If you open it in XSE you'll see the whole thing. It would probably be easier to edit it in XSE than in Hex Workshop. Just don't remove the loadpointer part of the script.

And for the record, 8F won't work in the second behavior byte slot as a basic script, but it will work in the first slot - but then you can't surf because you've changed the behavior byte that lets you surf.

This tutorial is really... crap.

I've done a research in one hour, and now i'm able to understand what happens for each behaviour byte.
And it wasnt very hard to find out how.

Also the behaviour byte 0x22 stands for the surfer script.
At first its a asm script which loads the offset of the gamescript into r0 and then it branches to a subroutine which starts the gamescript... by asm, you understand?

Its quite easy to find out how it works, give your best, research it and this tutorial will be one of the best i've ever seen ;D

Every door is open with the information you can get by researching the behaviour bytes.

I can't find another behavior byte for a question, so it could run another script. Can someone please tell me another one?

Take one with another text script. In the indoor tileset you can find many of these behaviour bytes.
Then search for the text in the rom, repoint it, find the scriptoffset, and repoint the script offset.
And now you've to change the pointer to the script offset, to a pointer to your offset.

haefele said:

Take one with another text script. In the indoor tileset you can find many of these behaviour bytes.
Then search for the text in the rom, repoint it, find the scriptoffset, and repoint the script offset.
And now you've to change the pointer to the script offset, to a pointer to your offset.

Click to expand...

I thought that but since its just text it doesn't have any script to run.

The text is a gamescript which is started by asm.
So if you find the offset of the gamescript, you can also find the pointer.
And so you can change the pointer to another script you want.

I've tested it, you can script like in other events.

Thanks for the tip. I'm going to try that.