![]() |
Quote:
|
Quote:
Quote:
Quote:
Quote:
Set Bike Speed to Walk speedHow to insert: Change byte at 0x150514 to 01 This has got to be the simplest thing here. lol. |
Can I request something that I hope is relatively straight forward? A routine which adds 1 to a variable after winning a trainer battle? Could be used to record victories, count winning streaks, etc.
|
Quote:
I'm not sure how you found that offset.. I've been looking for it for a long time. Despite, it still partially does not work. Registering the bike is glitched up. You can register it fine, you can click select and use it fine, however you cannot recall it. I think I have a slight understanding why this is, but I have absolutely no idea how I could fix this. Do you, just maybe, know how it could be done? :) |
Quote:
Using Darthatron's script item hack, you can call FBI' overworld change with the code Playsong 0x## 0x1 the 0x1 will act like the bike music (ie only change after map change, not a trainer/wild battle). |
Quote:
|
Quote:
|
I'm right! The naming routine is very interesting :D
edit: I can't understand the Re-usable TM's. (This one). It says: Quote:
Am I just dumb or ... |
Quote:
|
Quote:
I'm confused of this: Quote:
|
I saw a post in the script help thread by Méw who said he was trying to make it so that when you make a warp script, when you warp a key item is also activated. I looked through all of XSE's commands and there is no command that uses an item. I think this is the right place to post this, but how possible is it to make an item activated when making a warp script? I'm assuming the only thing the routine would involve is using an item, and the script does the rest..
|
Quote:
|
Battle by turn addon HP-regenBefore inserting this routine, you need to have the battle by turn routine enabled. See first post for that. Intro: A simple routine which adds HP regeneration to a Pokemon every odd turn of battle. The amount added can be changed (read the comment in the code). How to insert: Insert as a new battle by turn routine specified by the battle by turn frame. No further instructions required. Spoiler:
Usage: No usage, it's automatic. Make sure you have set the battle by turn flag. |
HP Regeneration per stepIntro: Basically a routine to regenerate a Pokemon's HP every step. In this routine it's set to 3 per step. You may want to modify the exact amount to a percentage or something (see the commented line). How to insert: First compile and insert the following routine into free space. Spoiler:
Now in a hex editor navigate to 0x6D5F6. There you will need to insert the following byte changes: Code:
Usage: There isn't any usage. It's automatically done. You can change the amount generated by reading the line in the code which I've commented. |
Quote:
Quote:
Quote:
|
Quote:
|
Quote:
|
|
Quote:
Quote:
Anyways, why do you want support for R/S or LG? They're all pretty bad bases to use. The biggest problem is their lack of research. It's pointless to research something for R/S when it's already been discovered for Emerald, because Emerald will be better than Ruby as a base, but never vise versa. It's just not worth the time researching things for a ROM base which is inferior. Fire Red has the most research done, and in my opinion, is the best base to use. Second comes Emerald, and finally the rest are trash. But, yeah, if you wanted to port them, the pointers are all that needs changing (for the ones you've linked). Actually, the surf one may be a little different depending on the base. Fire Red launches that routine when "A" is pressed on any tile. Other bases may be a little different. |
Quote:
Quote:
|
Field MovesThis, I think, deserves it's own thread. However, since I'd have about 90 threads by now if I followed that logic, I'm just going to make a post. I hope to cover how to add any arbitrary field move in addition to some research notes on the matter. This requires a little bit of patience and some table repointing/hex work in order to do. I should say that it's nothing hard, the hardest thing would be repointing a table, which is relatively easy. If you don't know how to do those hex manipulations, ask at the quick question thread, and hopefully myself or someone else will answer. Research for Nerds:Hi, if you're a noob just passing through trying to insert this without caring about the technical details, you can skip this section. Here I will be explaining as much as I know about the BRM for those who want to improve it or are generally curious about how it works in general. The BRM menu is by far one of the more complicated data structures in the game. It's handled by several separate RAM and ROM data structures which I will attempt to explain. The first one is the BRM's RAM data structure. There are a few attributes which this structure contains, the main one, the one we care about in this case is the cursor's position. It's given in 0203B0A9 and changes depending on which Pokemon you're hovering over. In the case you're in a selection where there are more than one Pokemon to be selected, the byte next to it will hold the second selection. This byte is used (when the player presses the "A" button) to derive other menus and checks by using the simple formula: 0x2024284 + (0x64 * byte) to get the Pokemon. There are a few others which are used to determine other things, which I don't be explaining in detail, mainly due to lack of my remembering (did this more than a month ago). Once the Pokemon is selected using the "A" button, contrary to initial belief, the BRM is generated on the spot, then graphically generated right after. Initially when "A" is pressed, the game loops through the 0x0 terminated Move IDs table comparing each half-word represented move to each move the Pokemon selected has at the function 0x81229FC. If a move is found, then it will store it in a RAM data structure (same BRM structure) which works very similarly to the start menu. This routine handles Pokemon holding mail too. With the given data structure fully formed the BRM is graphically created. There are some other things that go into it to pull up the "summary, cancel, item" fields and such (byte toggled in the BRM) but I'm not going to go too deeply about that. Anyways, the BRM RAM structure then handles the browsing of this smaller menu. Once "A" is pressed, the BRM table is used to determine which function to execute. It's format is [string pointer][routine pointer]. The HMs are at the end of this table. 0x81245A4 handles teh case where the selected item in an HM. It does things from badge checking to calling the actual routine, specific to the HM. In general, you can edit the table for the BRM to change a function to execute a routine of your choosing. However, remember that you need to follow the correct procedures which including closing the BRM and exiting to Overworld ect. The graphics generation and such are left to you if you follow this method. Initially, this is the method I was using. With some research, and studying, I was able to determine how the BRM item selection worked for HMs which excited to the overworld and called a routine. From there I was able to call a routine which ran a script. Basically, there were other RAM locations allocated to hold routine pointers which were executed by the game at certain times. Cut for example, would first check the map, the tiles infront of the player (if they were grass), the coords infront of the player, ect. before executing. From there, there were two cases which executed differently. Believe it or not, cut does not always execute a script. The first method is that it sets the tiles infront of the player to plain grass (so it actually cuts wild grass, try it yourself by walking into a patch of grass and using CUT !), the second case it executed the script. I think it's better to read the rest of the tutorial to see how those things work, rather than listening to my kinda long explanations. Repointing some tables (noob friendly edition):Before we begin, there are a few tables which need repointing. Please write down the offsets to where you paste the hex I give you. For your sake, once again, please write down where you place these tables to. Table 1: Move IDs table: Copy and place into free space: Make sure the offset you copied this table to is half-word divisible (ends in 0, 2, 4, 6, 8, A, C, E) Code:
Now navigate to 0x122A7C and change the reverse hex pointer to be the pointer where you copied the above hex table to. Table 2: Launch Pad routine table + properties Copy and place into free space: Make sure the free space offset is word divisible (ends in 0, 4, 8, C) Code:
Table 3: BRM names + launcher Copy and place into free space: Make sure the free space offset is word divisible (ends in 0, 4, 8, C) Code:
Table 4: Field move description pointers table Copy and place into free space: Make sure the free space offset is word divisible (ends in 0, 4, 8, C) Code:
That's all for table repointing. I hope you wrote down the offsets for them in some recognizable format. I.e: Table 1: Offset Table 2: Offset Table 3: Offset Table 4: Offset Because that's how I will refer to them AND we'll need them very soon. Making your move's script -> The fuelYou are lucky. You are lucky I suffered many hours figuring this out so you can use scripts rather than routines and have an easy time setting up field moves. Anyways, the first step is to write out your script which you will be using. In this "tutorial/resource/research" thing I will be inserting Sunny Day in an attempt to give a relevant example of how to set things up. Here's my PKSV script: Spoiler:
If you're lost at the script, or don't know how to make a script, then you'd better go learn! This script is admittedly, a little more complicated than what I'd expect people to use. Its because I'm using some scripting and ASM knowledge to determine whether or not we're indoors. It's a special case only relevant to weather effects. The rest of the script is normal. Note that your script can be pretty much anything, but please beware of the recursion limits (i.e calling callasm and that ASM calling a script...ect..). Once you've written the script, compile it to free space, and write down where you've compiled the script. Mine compiled to 0x740001 for example. Setting up our Phase 2 routine -> The RocketOnce you've compiled a suitable script, and tested the script individually to make sure it works, you're ready to set up your rocket. I call it Rocket because this routine will be the one calling the script. It will also be the routine which is called by our launchpad routine. Anyways, more on that later. Code:
Once again, write down the offset in which you've compiled the routine into and make sure you've inserted this routine into a word aligned offset. Setting up our Phase 1 routine -> The LaunchpadThis routine is going to be our Phase 1 routine. This routine will do the initial checks we want and then call the rocket routine. Actually, this structure is a little weird, because you can just as easily fulfill it's functionalities within the second routine. I've yet to figure out the reason as to why this is, but it just is this way. Code:
String setupOur last task before modifying some tables is to set up the string descriptions which will be brought up when the move is hovered over. The first task is to create the string. My string will be, "Makes it Sunny outside!". This in Hex is "C7D5DFD9E700DDE800CDE9E2E2ED00E3E9E8E7DDD8D9AB". Lastly, the game doesn't know how long or when the string ends. It's required that we specify this by using the string terminating character. This in FireRed (and actually all ROMs in gen III) is 0xFF. So the string then becomes "C7D5DFD9E700DDE800CDE9E2E2ED00E3E9E8E7DDD8D9ABFF". If you're not sure how to convert an ASCII string to HEX without messing it up, then I'll tell you that there's a 1-1 correspondence between the two. Use this table to generate a string, or you can use this Python program I wrote (if you have Python). Remember that the size of the string is also limited. I don't recall how many characters will fit before overflow, but keep it about 20 Characters long max. Table: Spoiler:
Python program: Spoiler:
Paste your Hex string into some free space in the ROM. Next, we need to find our Move's name in hex. I recommend finding it in the Move name table at 0x247094. Here's a simple formula you can use to find it: Offset = 0x247094 + (0xD * MoveID) Where MoveID is the move index number. Pound is 0x1 for example. It should be noted that if you have expanded the move tables via MrDS's patch or on your own, that 0x247094 won't be the correct offset. Actually, I think his patch is bugged here because the BRM table uses points in the old table, which he couldn't possibly have repointed without knowing. Anyways, it doesn't prove a problem unless you plan to make one of the expanded move names to appear using the move name table. Write down the offset of your move name as well as the description pointer. Editing the tablesHere are the important offsets you should have written: Table 1-4 locations Phase 1 routine: Launcher Move Description pointer Move Name pointer Firstly, we're going to handle Table 1 first. This is a table of reversed half-word move IDs. The game reads these ID numbers using ldrh (load half-word) which internally reverses them. ldr is the same functionality, that why we need to reverse hex our routine pointers and various other things. Anyways, I'm getting off topic, so I'm going to explain what to do to this table. The table itself is 0C 00 terminated, which is both weird and bad. Weird because 0xC is Guillotine, bad because someone may be interested in using Guillotine as a field move. So first of all, before we attempt anything, we'll be changing how the game reads this table, to terminate it upon reading 0x0 (which in the hex editor is 00 00 because it should be a half word), since 0x0 represents null move. To do this, navigate to 0x122A8C and change the byte from 0C to 00. Finally, edit your table to include the Move IDs of the field moves you want. My table for example looks like this right now: Quote:
F0: Rain dance, 59: Earthquake, 57: Thunder, C9: Sandstorm, F1: Sunny day. Then at the end I put in the "00 00" to show the end of the move detection table. Make sure your table is of similar format, except with the move IDs you want. After these edits go in game, and check if your game freezes upon pressing "a" on the selected Pokemon. If it does, then your table is messed up OR you've messed up something with these last few steps. The expected result is that you get weird characters (or no chars at all) in blue if your Pokemon has a move whose ID is in the table. We will be fixing these "glitched" names and such soon. Don't try using the move outside of battle yet, because you will crash your game. We're going to briefly skip table 2, and go onto table 3. This table is a little weird, because it's not terminated at all. It's browsed using an index number. Generally the moves are at the bottom, and each successive move in the move ID table is 1 entry past the last entry. So in short, for every move we add the the move ID table (table 1) we need to add an entry to this table (table 3). Table 3 is formatted: [4 bytes (Pointer to name)] [4 bytes (Pointer to Routine)] If you're doing to launch a routine instead of a script, the pointer to routine will be your routine's address +1. The chances are, you're going to use a script though. So farmat your entries like this: [Move name pointer (4 bytes)][081245A5 - BRM HM launching sequence]. Navigate to the word aligned offset you placed table 3 in, and add the following 8 bytes: Code:
After these edits, test it again. This time the blue gibberish should've turned into a move name. If it hasn't, you've messed up somewhere above. Now we'll edit table 2, this will make selecting the move actually do something. Table 2 consists of a routine pointer that is called by the routine 081245A4, as well as a mode. 95% of the time this mode is 0xD (the other mode is 0x10 used for Milkdrink and Softboiled). The routine pointer is simply going to be a pointer to Phase 1 routine: Launcher (which you should have written down). Like table 3, this is browsed by index and isn't terminated by a byte or sequence of bytes. So simply add to the end of the table, the following hex string: Code:
After these edits, test your game again. This time, everything should be fully functional. Routine should be called, and the whole effect should happen. If it doesn't, you've done something wrong in the above steps. Finally, we're on the last step, it's to change the move description which pops up when the move is highlighted. The Move Description pointer which you should have written down is what I'm referring to. In Table 4, simply append the move description pointer. That's it, you've successfully added a new field move! My condition for using this hackUnlike most hacks, this is a little different. It's open source, and you're free to use it. However, I require you post the script you use for any of your moves. This is because I want people to keep anything regarding this hack public. Just post the script you use in your own thread, and that'll be it (like the Sunny Day script I used). |
Button detection in scriptsIntro: There are a few hacks already existing which detect a button the player has pressed, but in my opinion they are a little over-complicated and unnecessary. There's a few RAM offsets which are allocated for I/O placed in the SuperState datastruture and keyinput bytes. However, reading these bytes in a script would give you the byte value in that specific frame. That's right, scripts run one command per frame (mostly. wait special, and other commands "pause" the cycle because the script pointer isn't updated). Anyways, inorder to do this, you'd need to write a task (which is also executed every frame) which detects a certain keypress. However, there already exists a command which pauses until a button is pressed. This command is the "waitbutton" command in PKSV or the "waitkeypress" command on XSE. We're going to be hacking this command to buffer the non-null button pressed into a variable. How to insert: First compile and insert into free space, the following routine Spoiler:
Now navigate to 0x6B89A and do the following byte changes: Code:
Usage: Basically you just call the waitbutton command and then read the variable 0x8000 to see which button was pressed. Here's an example script: Code:
Code:
|
Quote:
1. Battle by turn routine: 850000 2. BbT table: 850040 (I already put at the first entry the sleep clause routine) 3. Sleep clause routine: 800050 Spoiler:
Then I insert 00 48 00 47 41 00 85 08 to 0x13cb0 Spoiler:
So, I'm about to test it but I'm not able to because whenever I battle a trainer/wild encountered pokemon, it freezes or restarts after the first round. Also, there are some cases of resetting when I encounter wild pokemon. I direly in need of these sleeping clause. Btw, I used MrDollSteak Rom base and JPAN's fire red Hacked Engine. Thanks in advance! |
Quote:
Code:
|
Quote:
|
| All times are GMT -8. The time now is 8:46 AM. |
![]()
© 2002 - 2018 The PokéCommunity™, pokecommunity.com.
Pokémon characters and images belong to The Pokémon Company International and Nintendo. This website is in no way affiliated with or endorsed by Nintendo, Creatures, GAMEFREAK, The Pokémon Company or The Pokémon Company International. We just love Pokémon.
All forum styles, their images (unless noted otherwise) and site designs are © 2002 - 2016 The PokéCommunity / PokéCommunity.com.
PokéCommunity™ is a trademark of The PokéCommunity. All rights reserved. Sponsor advertisements do not imply our endorsement of that product or service. User generated content remains the property of its creator.
Acknowledgements
Use of PokéCommunity Assets
vB Optimise by DragonByte Technologies Ltd © 2023.