View Single Post
  #174    
Old January 23rd, 2010, 12:23 PM
JPAN
pokemon rom researcher
 
Join Date: Dec 2008
Quote:
Originally Posted by mindfreak View Post
I'm really confused with the overworld stuf.
If I make a new pointer here V
B0FD3908 B0FF3908 B0FE3908 New pointer
What table is it?
(The manual said that only one was occupied but there are already 3 pointers. so is it 0x1 or 0x3)
My bad. I accidentaly left some debug table addresses in the main table. Remove them and place your pointer on the second slot (b0ff3908), and delete the third. In that case, it will be 1.
If you wanted to keep the tables, then it would be 0x3, as you suggested.
Quote:
Originally Posted by mindfreak View Post
And how can I display the new overworlds ingame?
(I tried by editing the event data in hexworkshop but failed.)
Look at the trainer flag hack area of the manual. I placed a picture there that explains the new data in the A-Map person event. Simply change the rightmost unknown byte, right below the picture number, to the table number. The change will not appear in A-Map, but in game it will be your sprite.

Quote:
Originally Posted by iTeruri View Post
Wait, so how does the item hack work?
I have a script compiled at 0x900000. I'm using Item Editor by Thethethethe. Where should I enter the offset? Because I can't find where the item table is located in the rom...
The item table starts at 0x3db028, and ends at 0x3df09c. If you can, after editing the Item in the Item editor, Open a table file in your hex editor and search for your item name, and it should pop up. If you can't open a table file, multiply the item number by 0x2c and add it to the base address.
When you reach the item, goto Item_adddress+ 0xE and make sure the item number is the same there as you input it (item 0x102 should have 02 01 in there). Then go to Item_address + 0x1b and make sure the value is 4. In Item_address + 0x1c, place the routine pointer (21 15 16 08 in the patch version) and in Item_address + 0x28 place the script pointer (00 00 90 08 in your case). Save, and it's good to go.

Right now I am working on increasing the amount of money you can have to One billion minus 1. And I've read the "increase the variables capacity", and I Have already planned to create a group of special functions to let the user treat a group of variables as a single one, but all those operations are on the user's risk, and must keep under consideration the range he wishes to use. As such, I will provide said functions on the next release, and should include add and subtract functions, buffer number functions for 32 bit, and support for more digits dynamically.

And the increase money hack is (apparently) complete! You can now hold up to 999 999 999 money! That's nearly 1000 times more money! If you don't want to wait for the next release to test it, know this was acomplished just by replacing 7 bytes, and here's how to do it:
at 0809fdd4 replace |3f 42 0f 00| for |ff c9 9a 3b|; (999999 for 999999999)
at 0808a006, 0809fe52 and 0809fe62, replace that one byte from |06| for |09|. (6 digit display for 9 digit display)
Done, you should be able to have that much money now.

EDIT: As this was moved to the Research and Development forum, I feel that now I can directly ask for opinions on future updates without going Off-topic. So, I will tell you what's going on and you tell me what you would like me to do.
Because Special editing is limitative (special is a 5 byte command tops, and so it cannot receive direct input through the script. Not that's impossible, just very unpractical), I've been looking at the commands in the scripting engine, in order to find how stuff works and where the "free" commands are. And I was surprised to find that, from Ruby to Fire Red, some commands changed their use dramatically, or simply went and did some stuff we are not expecting. One example is the "copyVarIfNotZero" command, that In Fire Red copies a variable, even if it is zero. The correct name, for it's usage, would be something like "copyVarOrSetIfNotVar", as there what it does is copy a variable if both words given are real variables (in the 0x4000-0x8013 range), and set the first variable to the second value if not a real variable (values up to 0x3fff). Copyvar, in the other end, simply is error-prone in this case. trying to write in illegal memory if the value is not a variable. So, in this case, should I try and correct the Copyvar method to be bug-free and make it so Copyvarifnotzero does what we expected it to do, or let it be?
Same is true for some other commands, such as addvar and subvar, that should be identical, but subvar allows the use of two variables, while addvar does not. Should I try and fix that too?
I will introduce a concept now. A "fake" command would be a command where the arguments that should be used (according with the script compilers such as XSE) are not the real argument numbers. For instance command 0x96 (unnamed as of yet) in Ruby takes 2 bytes as arguments. In FR, it takes no arguments, as in there it's a simple nop command. The opposite could also be true: commands that use more bytes than we thought they would. Stuff like startContest, which have no use in FR, and occupies only one byte (correct in both versions) could be replaced with a command that receives data and consumes bytes, in order to make it easier to use certain commands (such as the VarMath special, that even I have trouble using). As that would cause some confusion in the script compilers code (there would have to be two separate set of Fire Red commands, one static and one dynamic that accompanied this hack), we could use a technique that Gamefreak used with its Trainerbattle command, where it can ignore certain bytes as to get specific information. As such, something like VarMaths multiply variables could be used like this:
Code:
#alias startContest mulVar
#org @start
mulvar
copyvar 0x8000 0x8001
end
Where the copyvar is nothing more than a holder for the two variables to multiply, and its opcode (0x19) is discarded, and would never happen. We would use it only to mantain the integral structure of the code, so decompiling this script wouldn't turn into something wierd that no-one could read.

So, with this concept in mind, should I in future hacks (and in corrections from older ones), allow "fake" commands to take place or keep with the current "setvar argument_var value" ... "special 0xNUM" format?
Here are the links for my work


Currently working on:
Battle Script Documentation
Another large project

Last edited by JPAN; January 23rd, 2010 at 07:55 PM. Reason: Getting feedback