JPAN
pokemon rom researcher
- 104
- Posts
- 16
- Years
- Seen Jul 2, 2016
From a request that started on the hacked engine thread came a question: "Now that we have a RTC system in Fire Red\Leaf Green, can we port the berry growth system from Ruby?" My answer to that was "Why not build one from scratch?" In this thread I will introduce the solution I came up with, but I feel can be somewhat improved. Also, as of the posting of this message, the berry system seems to work ok on the two-week trial it went through, but I would appreciate any help debugging and replacing problematic areas of code.
First of all, I must say this code is built on top of a normal US Fire Red ROM with only the Day Night System by Interdpth & ZodiacDaGreat, using the Real Time Clock that comes with it. I would like to give credit to them for this great hack, and without which this would not be possible. I also use the code base for the hacked engine on the key-inserting and the OW hacks, and this latest is required for the correct working of this tool.
Starting from the top:
What is a berry tree?
Berry trees are Overworld sprites, similar to any other, except they change with time. That time may pass by in-game or outside of the game, as the RTC will keep the game updated in either cases. Besides this outside look, they also need to store somewhere information about them, such as time since planted or watered, or what kind of berry tree it is.
So, we can define a berry tree as an OW that changes with time and user interaction, and gives the player an item after a number of conditions are met.
Where do we store that information? Variables are good, since they keep memory after the game is shut down. But can all information needed to be kept stored in a variable? Unfortunately, no. We need at least two variables for each tree.
How is a berry tree made?
This is the creative part. The official R/S/E berry tree is stored differently from the other OW's, and has its own sets of rules. They keep a memory area reserved for them, that the OW loader accesses direclty, and use a script with specials to obtain which area they are using, the berry growing there and the berry growth stage.
In this approach, we will consider an hybrid model between R/S/E and D/P/Pt. Basically, a berry tree has two variables(with bit 0 being the least significant):
This approach considers the possibility to use damp and growth mulch on the berry after it was planted.
Another think to note is the timespan. The time passed cannot be big enough to make one note a difference (one hour-apart updates would make a berry that was just planted to grow at the same time one that was planted 50 minutes ago) but not small enough to take much space (if in seconds, one day was too long for one variable). For this implementation, the timespan is one minute, that allows for a maximum livespan of 45 days and a half (0xfff0). As it seems impratical for such a long time, and because it's hard to make compares with this value, the day limit was set at 32 (0xb400).
The berry information, shown in the first variable, is one byte long, too small to be the berry item number. Also, up until now we talked numbers, but what about the graphics?
How does the game displays the correct berry tree?
Once again, the official solution would do us no good. it involves some maths with the frame to display on the sole tree OW data, and some more maths to find the correct palette, and all of this using the data from the special memory area that we don't have. The solution for this is the use of a Dynamic OW hack to display the tree we need. But how does it know the correct image and when to display it? The solution is the creation of a Berry table, where the berry information byte is the index. That table is composed as this:
This table allows anyone to design their own berry system, but it's more flexible than that. You can even design special events that take some time after you activate them to change into the event that you wanted it to. But it's main use is the berry system we come here to do. Simply slide the OW number and the time you need in the respective slot, the items it must give in the item slot and how many to give in the min_item slot and you get a berry tree for the item you wanted. The OW format is (OW table number) (OW number), as it was meant to be used with the OW hack.
So, as an example, let's assume you have an oran berry tree's sprites stored (in order) in the positions 0-4 of your sprite table 0x5, and the ones for a sitrus berry tree in 5-7 (last three stages only). We assume that one oran tree gives 2-8 berries and sitrus gives 1-4 berries. We want the same times as the original version and we want oran as the first one and sitrus as the second. the table would look like this (| indicates end of berry):
The item minimum has double meaning, as the number of berries is currently calculated as min*watered_times.
So, after all this long explanation on the ways this new berry system will work, it's time to put it into practice.
All this code is useless if it is never used. So first of all, we need a function that, in game, runs at least once every minute, even if the player stays still. For that role, I chose the key reader.
The key reader function is a special function that runs since the game begins to the moment you turn the power off. The keyboard may be pressed at any time, and as such, this function needs to read it frequently. More than once a minute. So, we take advantage of it, and place a small hack when it is called so that if a minute has passed since it last ran, a code is executed, and if not, simply carry on, with as little delay as possible. For that, I used a small memory room, not managed, at the position 0x0203f3f0. This code is the same as the one used for the key-pressing changes, so I'll only highlight the important piece of code in it, but will post it completely for testing purposes.
This last code takes care or the in-game update problem by making sure the game updates all variables in the given interval. But the key finder is used even before the game is loaded (title screen). To prevent the game from trying to update non-existing berries, the first condition was created. Checking if the time counter is 0 makes it possible to check if the game has started yet, as long as we use a non-0 number to initialize it when we want it to run. That problem comes into contact with the out-game time passage.
The RTC doesn't run the game code to make sure berries are updated, so we need to create a system that allows the player to leave his game unattended for a large period of time without losing its berries. For that the next routine was created. A first problem encountered is that, to my knowledge, the clock time from the last save is not stored anwywhere. For that, I used two variables (0x4090 and 0x4091) to store the time. Also, as room was lacking, I saved only month, day, hour and minute of the last save. That means that if you played a hack using this system a year after you put it down, everything would be the same as when you left. Another problem was where to put it. It is expensive, so ideally we should run it only once, but what routines run only once just as soon the game loads? First attempt was made with the routine at 0xcc94, responsible for the fadescreen after the game is loaded in the starting screen, both for "continue" and "new game". But another problem ensued. When that routine is called, it loads the game, but uses the variable's space to determine the "last on" scene when it continues. at the end of that, another routine loads the variables again, and that routine is called through the WRAM Stack area, making it almost untraceable. So, as an alternative, I went with the collision detector. The function is located at 0x0806d698, and handles all movement. It doesn't, however, run until you move. So this is a somewhat poor replacement function, but since we believe that every person that plays the game will eventually walk around it, it's not that bad. All this code is relevant to the subject at hand
Finally, we need to be able to change the image of the OW. Some theories came to mind on how to do this one, but in the end I ended up with the following:
There is a limit of 256 different berry slots, each identified in the person id by the table number 0xfe. The game, when loading the OW, checks its table number, and in the same way Dynamic OWs were created, he also checks to see what it should print. It goes to the Plant variable, checks for the table index of that entry, calculates the current time on that variable to get its stage, and finally prints the corresponding OW. The code is as follows: (what matters in BOLD)
This code is meant to replace the one at the OW hack. As such, if you want to use it, I would appreciate you compile this code and simply replace the one at the hacked engine tool version, the file "ow_main.out". I will not post the rest of the required code for the OW hack, as it is not the main topic here, and it's too big to post.
Another problem present is how to keep the time the game was last updated. The out-game updating routine takes care of updating the time it was executed, but there was no need to save every minute. All we need is for the variable to be up-to-date as we save the game. So, I created this save hack that saves the variable when the save screen is shown:
This code is quite similar to the one that does the same thing at the long-term update function, but this one has all the things the game needs to continue with the save function, where the other one doesn't.
I finished a routine that gets the planted item, as well as the quantity produced. The formula to the number of items was previously mentioned, but there is a special case that when it's 0, it will give 2 if always watered and 1 otherwise. It uses variables 0x8004 and 0x8005, and returns to 0x8004 and to r0 the item and to 0x8005 returns the number of items. This code is supposed to be used with a callasm or included in an empty special.
That's what I've got so far. To be a fully functional berry tree hack, it still needs the gets and sets of this type, that is:
planting routine;
add mulch routine;
watering routine;
Check tree state routine;
Check watered time routine;
Berry script.
So, before I leave, I have some questions I need to raise.
First, how do you thing the planting should be done? It's two simple setvars, one for the plant and one for the timer, but how will we find the item the player wants to plant, and its position on the table?
Second, do you think it would be more appropriate to change the OW hack to instead of reading of a variable, reading a set of variables concerning where it is? For instance, its not var sprite 0x0, table 0xfe = var 0x7d00 plant, but rather sprite 0x0, table 0xfe = a fixed variable that contains the plant variable. Having regional variables can increase the number of berries possible, but is it really necessary to have more than 256 berry plants? And if so, what would be a good number of variables to set apart for a map script to change?
Third, do you think the item number should be determined by the given formula, or would you prefer something more like the 0 case (the byte only represents a mode)?
First of all, I must say this code is built on top of a normal US Fire Red ROM with only the Day Night System by Interdpth & ZodiacDaGreat, using the Real Time Clock that comes with it. I would like to give credit to them for this great hack, and without which this would not be possible. I also use the code base for the hacked engine on the key-inserting and the OW hacks, and this latest is required for the correct working of this tool.
Starting from the top:
What is a berry tree?
Berry trees are Overworld sprites, similar to any other, except they change with time. That time may pass by in-game or outside of the game, as the RTC will keep the game updated in either cases. Besides this outside look, they also need to store somewhere information about them, such as time since planted or watered, or what kind of berry tree it is.
So, we can define a berry tree as an OW that changes with time and user interaction, and gives the player an item after a number of conditions are met.
Where do we store that information? Variables are good, since they keep memory after the game is shut down. But can all information needed to be kept stored in a variable? Unfortunately, no. We need at least two variables for each tree.
How is a berry tree made?
This is the creative part. The official R/S/E berry tree is stored differently from the other OW's, and has its own sets of rules. They keep a memory area reserved for them, that the OW loader accesses direclty, and use a script with specials to obtain which area they are using, the berry growing there and the berry growth stage.
In this approach, we will consider an hybrid model between R/S/E and D/P/Pt. Basically, a berry tree has two variables(with bit 0 being the least significant):
Code:
First Variable - Plant info
first byte - "Berry" information
bits 8-12 - Watered times
bit 13 - grow at 2x speed
bit 14 - grow at 1/2 speed
bit 15 - watered at this stage
Code:
Second Variable - Plant timer
2 bytes time passedAnother think to note is the timespan. The time passed cannot be big enough to make one note a difference (one hour-apart updates would make a berry that was just planted to grow at the same time one that was planted 50 minutes ago) but not small enough to take much space (if in seconds, one day was too long for one variable). For this implementation, the timespan is one minute, that allows for a maximum livespan of 45 days and a half (0xfff0). As it seems impratical for such a long time, and because it's hard to make compares with this value, the day limit was set at 32 (0xb400).
The berry information, shown in the first variable, is one byte long, too small to be the berry item number. Also, up until now we talked numbers, but what about the graphics?
How does the game displays the correct berry tree?
Once again, the official solution would do us no good. it involves some maths with the frame to display on the sole tree OW data, and some more maths to find the correct palette, and all of this using the data from the special memory area that we don't have. The solution for this is the use of a Dynamic OW hack to display the tree we need. But how does it know the correct image and when to display it? The solution is the creation of a Berry table, where the berry information byte is the index. That table is composed as this:
Code:
The Berry Tree Table
2 byte item number
1 byte empty (for now)
1 byte min item quantity
2 byte time it has in seed stage
2 byte OW for seed stage
2 byte time in sprout stage
2 byte OW for sprout
2 byte time in half-grown stage
2 byte OW for half-grown stage
2 byte time in full grown
2 byte OW for full-grown
2 byte time to go back to seed
2 bytes OW for ripeSo, as an example, let's assume you have an oran berry tree's sprites stored (in order) in the positions 0-4 of your sprite table 0x5, and the ones for a sitrus berry tree in 5-7 (last three stages only). We assume that one oran tree gives 2-8 berries and sitrus gives 1-4 berries. We want the same times as the original version and we want oran as the first one and sitrus as the second. the table would look like this (| indicates end of berry):
Code:
8b 00 00 02 b4 00 05 00 68 01 05 01 1c 02 05 02
d0 02 05 03 84 03 05 04|8e 00 00 01 68 01 05 00
d0 02 05 01 38 04 05 05 a0 05 05 06 08 07 05 07|So, after all this long explanation on the ways this new berry system will work, it's time to put it into practice.
All this code is useless if it is never used. So first of all, we need a function that, in game, runs at least once every minute, even if the player stays still. For that role, I chose the key reader.
The key reader function is a special function that runs since the game begins to the moment you turn the power off. The keyboard may be pressed at any time, and as such, this function needs to read it frequently. More than once a minute. So, we take advantage of it, and place a small hack when it is called so that if a minute has passed since it last ran, a code is executed, and if not, simply carry on, with as little delay as possible. For that, I used a small memory room, not managed, at the position 0x0203f3f0. This code is the same as the one used for the key-pressing changes, so I'll only highlight the important piece of code in it, but will post it completely for testing purposes.
Code:
/*place the pointer to this function at 0x08000624, and change 0x080005ec to 00 47 */
Key_wrecker_start: push {r4-r7}
bl add_var_routine
ldr r0, key_addr
ldrh r0, [r0]
ldr r4, switches
ldrb r1, [r4]
cmp r1, #0x0
beq nothing_to_do
bl check_for_script
bl check_for_forced
bl check_for_cancel
nothing_to_do: pop {r4-r7}
add r1, r0, #0x0
ldr r0, return_place
bx r0
.hword 0x0000
key_addr: .word 0x04000130
switches: .word 0x0203f4ec
return_place: .word 0x080005ef
check_for_script: push {r0-r1,lr}
mov r2, #0x4 /*check for flag*/
and r2, r1
cmp r2, #0x0
beq end_all
ldr r5, script_on /*check if a script is executing*/
ldrb r3, [r5]
cmp r3, #0x1
beq end_all
ldrh r2, [r4, #0x2] /*check if the keys are pressed*/
and r2, r0
cmp r2, #0x0
bne end_all
ldr r3, first_function /*checks if we are in the OW*/
ldr r2, [r3]
ldr r3, OW_function
cmp r2, r3
bne end_all
mov r2, #0x1 /*if all is ok, run script*/
strb r2, [r5]
ldr r0, [r4, #0x8]
bl script_executer
end_all: pop {r0-r1,pc}
script_on: .word 0x03000f9c
first_function: .word 0x03005090
OW_function: .word 0x08079e0d
check_for_forced: push {lr}
mov r2, #0x1 /*check for flag*/
and r2, r1
cmp r2, #0x0
beq end_all_2
ldrb r2, [r4, #0x1] /*check if it should apply it*/
cmp r2, #0x0
beq end_all_2
sub r2, #0x1
strb r2, [r4, #0x1] /*updates counter*/
sub r4, #0xE
ldrh r2, [r4] /*gets keymap to force*/
add r4, #0xe
mvn r2, r2
and r0, r2 /*keys changed*/
end_all_2: pop {pc}
check_for_cancel: push {lr}
mov r2, #0x2 /*check for flag*/
and r2, r1
cmp r2, #0x0
beq end_all_3
ldr r2, [r4, #0x10] /*loads key to ignore*/
orr r0, r2 /*ignored*/
end_all_3: pop {pc}
script_executer: ldr r1, exe_addr
bx r1
exe_addr: .word 0x08069AE5
[B]add_var_routine: ldr r1, last_time[/B]
[B] ldrb r0, [r1][/B]
[B] cmp r0, #0x0 /*if timer is 0, nothing to do yet*/[/B]
[B] beq end_this[/B]
[B] sub r0, #0x1[/B]
[B] ldr r2, timer_min[/B]
[B] ldrb r2, [r2][/B]
[B] cmp r2, r0[/B]
[B] beq end_this[/B]
[B]timer_update: add r2, #0x1[/B]
[B] strb r2, [r1][/B]
[B] push {r4-r7, lr}[/B]
[B] ldr r7, var_plant[/B]
[B] ldr r6, var_plant_time[/B]
[B] mov r5, #0xff[/B]
[B] ldr r4, berry_table [/B]
[B]timer_up_loop: add r0, r7, #0x0[/B]
[B] bl call_var_decrypt[/B]
[B] ldrh r1, [r0][/B]
[B] cmp r1, #0x0[/B]
[B] beq next_plant[/B]
[B] bl time_and_water[/B]
[B]next_plant: sub r5, #0x1[/B]
[B] add r7, #0x1[/B]
[B] add r6, #0x1[/B]
[B] cmp r5, #0x0[/B]
[B] bge timer_up_loop[/B]
[B] pop {r4-r7,pc}[/B]
[B]end_this: mov pc, lr[/B]
[B].hword 0x0000 [/B]
[B]var_plant: .word 0x00007d00 /*intput your plant variables here*/[/B]
[B]var_plant_time: .word 0x00007e00[/B]
[B]last_time: .word 0x0203f3f0[/B]
[B]timer_min: .word 0x03005543[/B]
[B]berry_table: .word 0x00000000 /*replace by your table*/[/B]
[B]/*this function will up the timer and allow you to water again after the plant has [/B][B]supposedly grown. this function is completely dependant on the above one*/[/B]
[B]time_and_water: push {r6,r7,lr}[/B]
[B] add r7, r0, #0x0[/B]
[B] add r0, r6, #0x0[/B]
[B] push {r1}[/B]
[B] bl call_var_decrypt[/B]
[B] pop {r1}[/B]
[B] add r6, r0, #0x0[/B]
[B] ldrh r2, [r0][/B]
[B] add r2, #0x1[/B]
[B] strh r2, [r0] /*stores the value first, to avoid problems*/[/B]
[B] lsl r3, r1, #0x18 [/B]
[B] lsr r3, r3, #0x18[/B]
[B] mov r0, #0x18[/B]
[B] mul r3, r0[/B]
[B] add r3, r4, r3[/B]
[B] bl time_ops[/B]
[B] ldrh r0, [r3, #0x4][/B]
[B] cmp r0, r2[/B]
[B] beq water_able[/B]
[B] ldrh r0, [r3, #0x8][/B]
[B] cmp r0, r2[/B]
[B] beq water_able[/B]
[B] ldrh r0, [r3, #0xc][/B]
[B] cmp r0, r2[/B]
[B] beq water_able[/B]
[B] ldrh r0, [r3, #0x10][/B]
[B] cmp r0, r2[/B]
[B] beq water_able[/B]
[B] ldrh r0, [r3, #0x14][/B]
[B] cmp r2, r0[/B]
[B] bge dispose_of[/B]
[B] pop {r6,r7,pc}[/B]
[B]water_able: lsl r1, r1, #0x11[/B]
[B] lsr r1, r1, #0x11 /*eliminates watered byte*/[/B]
[B] strh r1, [r7][/B]
[B] pop {r6,r7,pc}[/B]
[B]dispose_of: lsl r1, r1, #0x18[/B]
[B] lsr r1, r1, #0x18[/B]
[B] strh r1, [r7] /*eliminates the old care bits*/[/B]
[B] sub r2, r2, r0 [/B]
[B] str r2, [r6] /*places 0 on the old spot.*/ [/B]
[B] pop {r6,r7,pc} [/B]
[B]call_var_decrypt: ldr r1, var_decrypt[/B]
[B] bx r1[/B]
[B]var_decrypt: .word 0x0806E455[/B]
[B]/*calculates the time appling the mulch effect*/[/B]
[B]time_ops: lsl r0, r1, #0x11[/B]
[B] lsr r0, r0, #0x1e [/B]
[B] cmp r0, #0x1[/B]
[B] beq half_time /*grows 2 times faster*/[/B]
[B] cmp r0, #0x2[/B]
[B] beq double_time /*takes double time to grow*/[/B]
[B] mov pc, lr[/B]
[B]half_time: lsr r2, r2, #0x1[/B]
[B] mov pc, lr[/B]
[B]double_time: lsl r2, r2, #0x1[/B]
[B] mov pc, lr[/B]The RTC doesn't run the game code to make sure berries are updated, so we need to create a system that allows the player to leave his game unattended for a large period of time without losing its berries. For that the next routine was created. A first problem encountered is that, to my knowledge, the clock time from the last save is not stored anwywhere. For that, I used two variables (0x4090 and 0x4091) to store the time. Also, as room was lacking, I saved only month, day, hour and minute of the last save. That means that if you played a hack using this system a year after you put it down, everything would be the same as when you left. Another problem was where to put it. It is expensive, so ideally we should run it only once, but what routines run only once just as soon the game loads? First attempt was made with the routine at 0xcc94, responsible for the fadescreen after the game is loaded in the starting screen, both for "continue" and "new game". But another problem ensued. When that routine is called, it loads the game, but uses the variable's space to determine the "last on" scene when it continues. at the end of that, another routine loads the variables again, and that routine is called through the WRAM Stack area, making it almost untraceable. So, as an alternative, I went with the collision detector. The function is located at 0x0806d698, and handles all movement. It doesn't, however, run until you move. So this is a somewhat poor replacement function, but since we believe that every person that plays the game will eventually walk around it, it's not that bad. All this code is relevant to the subject at hand
Code:
/*To make sure this is run, place bx r0 (00 47) at 0806d6a8, and place the pointer to this
at 0x0806D6E0
*/
/*r7 keeps the plant variable and r6 the timer variable associated
r5 is the variables remaining counter and r4 is the time that passed.
this code is divided in two separate versions, one for when over 32 days passed and one
for when less than 32 days passed. The first is called the Overflowed version, and the
second regular version. The overflowed version is labled.
*/
Berry_time: ldr r1, last_time
ldrb r1, [r1]
cmp r1, #0x0 /*the check for if this code already ran once*/
bne real_exit
push {r0-r7}
ldr r7, var_plant
ldr r6, var_plant_time
bl get_time
add r4, r0, #0x0
mov r5, #0xff
cmp r1, #0x1
beq overflowed
timer_up_loop: add r0, r7, #0x0 /*the extensive check verison*/
bl call_var_decrypt
ldrh r1, [r0]
cmp r1, #0x0 /*checks if there is a berry in there*/
beq next_plant
add r2, r6, #0x0
bl add_and_store_berry
next_plant: sub r5, #0x1
add r7, #0x1
add r6, #0x1
cmp r5, #0x0
bge timer_up_loop
b almost_exit
var_plant: .word 0x00007d00 /*replace for your own variables here*/
var_plant_time: .word 0x00007e00
.hword 0x0000
overflowed: add r0, r7, #0x0
bl call_var_decrypt
ldrh r1, [r0]
cmp r1, #0x0
beq next_plant_2
lsl r1, r1, #0x18 /*erase watering and mulch bytes*/
lsr r1, r1, #0x18 /*as they are no longer valid*/
strh r1, [r0]
add r2, r6, #0x0
bl add_n_store_berry /*different function, as it doesn't search for water*/
/*bits*/
next_plant_2: sub r5, #0x1
add r7, #0x1
add r6, #0x1
cmp r5, #0x0
bge overflowed
almost_exit: ldr r0, timer_var
bl call_var_decrypt
add r1, r0, #0x0
ldr r0, rtc_time
ldr r3, last_time
ldrb r2, [r0, #0x4]
add r2, #0x1
strb r2, [r3] /*places the minute+1 in the slot*/
/*making this happen no more*/
bl replace_old_time
pop {r0-r7}
real_exit: ldr r0, addr_adfa
ldrb r0, [r0, #0x7]
ldr r1, ret_addr
bx r1
last_time: .word 0x0203f3f0
timer_var: .word 0x00004090 /*variables that keep the last known time*/
rtc_time: .word 0x0300553f
addr_adfa: .word 0x0203adfa
ret_addr: .word 0x0806d6ab
/*this function calculates the time very thorughly (except february 29th is not included)
receives nothing and returns in r0 the time difference, in minutes, from the latest
recorded time and the one currently on the RTC.
modified so it fits the max berry time interval, and r1 as a flag determining if the time
value has been exceeded.*/
.hword 0x0000
get_time: push {r4-r7,lr}
ldr r4, var_time
add r0, r4, #0x0
bl call_var_decrypt
ldr r5, [r0] /*in the format month, day, hour, minute*/
add r6, r0, #0x0 /*for later storage*/
mov r7, #0x0 /*cleans r7, as it will be the timer counter*/
ldr r4, cur_time
ldrb r0, [r4, #0x4]
lsl r1, r5, #0x18
lsr r1, r1, #0x18
cmp r0, r1
beq check_hour
cmp r0, r1
bgt total_minute
add r0, #0x3c /*adds one hour*/
mov r2, #0x1
lsl r2, r2, #0x8 /*"one hour"*/
sub r5, r5, r2 /*hour removed for further calculus*/
total_minute: sub r7, r0, r1 /*places the passed minutes at the counter*/
check_hour: lsl r1, r5, #0x10
lsr r1, r1, #0x18
ldrb r0, [r4, #0x3]
cmp r0, r1
beq check_day
cmp r0, r1
bgt total_hour
add r0, #0x18 /*adds one day*/
mov r2, #0x1
lsl r2, r2, #0x10 /*"one day"*/
sub r5, r5, r2 /*one day less*/
total_hour: mov r2, #0x3c
sub r0, r0, r1
mul r0, r2 /*turns hours into minutes*/
add r7, r7, r0
check_day: lsl r1, r5, #0x8
lsr r1, r1, #0x18
ldrb r0, [r4, #0x1]
cmp r0, r1
beq check_month
cmp r0, r1
bgt total_days
lsr r2, r5, #0x18 /*gets current month*/
sub r2, #0x1 /*gets the month before it*/
cmp r2, #0x0 /*if month before is december*/
bne get_month_day
mov r2, #0xc
get_month_day: bl month_to_day
add r0, r2, r0
mov r2, #0x1
lsl r2, r2, #0x18
sub r5, r5, r2 /*takes a month away*/
total_days: sub r0, r0, r1
mov r2, #0x5a
lsl r2, r2, #0x4 /* minutes_per_day*/
mul r0, r2
add r7, r0, r7
/*the last one is trickier, as we need to add the days of each month one by one */
check_month: lsr r1, r5, #0x18
cmp r1, #0x0 /*may happen if to january we subtract 1 (december)*/
bne month_load
mov r1, #0xc
month_load: ldrb r0, [r4] /*after this point, r4-r6 contents are useless*/
cmp r0, r1
beq check_size
mov r5, #0x5a
lsl r5, r5, #0x4
cmp r0, r1
bgt bigger_month
over_december: cmp r1, #0xd
beq for_normal
add r2, r1, #0x0
bl month_to_day
mul r2, r5
add r7, r2, r7
add r1, #0x1
b over_december
for_normal: cmp r0, #0x1
beq check_size
mov r1, #0x1
bigger_month: add r2, r1, #0x0
bl month_to_day
mul r2, r5
add r7, r2, r7
add r1, #0x1
cmp r0, r1
bgt bigger_month
/*size check so it won't go over 0xb400, the 32-day limit imposed on berries. this limit
can be upped to 45 and a half days (0xfff0), tops. the 32 day limit seemed appropriate and
low-cost and speedy on the machine*/
check_size: mov r2, #0xb4
lsl r2, r2, #0x8
cmp r7, r2
bgt special_flag
add r0, r7, #0x0
mov r1, #0x0
pop {r4-r7, pc}
special_flag: mov r1, #0x1
norm_loop: sub r7, r7, r2
cmp r7, r2
bgt norm_loop
add r0, r7, #0x0
pop {r4-r7, pc}
var_time: .word 0x00004090 /*choose your own, as long as it's even*/
cur_time: .word 0x0300553f
/*Converts the month given in a ammount of days
receives r2 as the month needed, as to not destroy r0 and r1
*/
month_to_day: ldr r3, month_time
sub r2, #0x1
add r3, r3, r2
ldrb r2, [r3]
mov pc, lr
.hword 0x0000
month_time: .word 0x00000000
days_of_month: .byte 0x1f
.byte 0x1c
.byte 0x1f
.byte 0x1e
.byte 0x1f
.byte 0x1e
.byte 0x1f
.byte 0x1f
.byte 0x1e
.byte 0x1f
.byte 0x1e
.byte 0x1f
/*A special function that adds the timer on for a berry, checking for water.
This is the function called by the regular verison, and is very expensive
receives r0 as the berry variable address, r1 as the content of r0, r2 as the berry timer
var, r4 as the timer value
returns nothing
*/
add_and_store_berry: push {r5-r7, lr}
add r6, r0, #0x0
ldr r5, berry_table
lsl r1, r1, #0x18
lsr r1, r1, #0x18
mov r3, #0x18
mul r1, r3
add r5, r1, r5 /*berry location in the table*/
add r0, r2, #0x0
bl call_var_decrypt
add r7, r0, #0x0
ldrh r2, [r7]
add r2, r4, r2
ldrh r3, [r5, #0x14]
bl time_calc /*corrects the time with the used mulch*/
cmp r2, r3
bge subtract_time
ldrh r0, [r7]
add r1, r5, #0x0 /*gets the stage the berry was on*/
bl get_stage
add r3, r0, #0x0
add r0, r2, #0x0
bl get_stage /*gets the stage the berry is now in*/
cmp r0, r3
beq store_and_end
ldrh r1, [r6] /*different, erase watered bit*/
lsl r1, r1, #0x11
lsr r1, r1, #0x11
strh r1, [r6]
b store_and_end
subtract_time: ldrh r1, [r6]
lsl r1, r1, #0x18
lsr r1, r1, #0x18
strh r1, [r6]
subtract_loop: sub r2, r2, r3
cmp r2, r3
bge subtract_loop
store_and_end: strh r2, [r7]
add r0, r6, #0x0
pop {r5-r7, pc}
/*second add function, without checks for the water byte
The one used in the overflown version.
receives r0 as the timer variable*/
add_n_store_berry: push {r5-r6, lr}
ldr r5, berry_table
mov r3, #0x18
mul r1, r3
add r5, r1, r5
bl call_var_decrypt
ldrh r2, [r0]
add r2, r4, r2
ldrh r3, [r5, #0x14]/*doesn't check for mulch*/
cmp r2, r3 /*as we know it's gone*/
blt end_add_n_store
sub_berry_loop: sub r2, r2, r3
cmp r2, r3
blt sub_berry_time_loop
end_add_n_store: strh r2, [r0]
pop {r5-r6, pc}
.hword 0x0000
berry_table: .word 0x090004e8
call_var_decrypt: ldr r1, var_decrypt
bx r1
var_decrypt: .word 0x0806E455
/*function to get the stage a tree with a certain number is at on a certain time.
r0 is the time value, r1 is the table position for the berry
returns in r0 the value for the stage, 0xff if over the max*/
get_stage: push {r3,r5, lr}
add r5, r1, #0x0
ldrh r3, [r5, #0x4]
bl time_calc
cmp r0, r3
blt first_stage
ldrh r3, [r5, #0x8]
bl time_calc
cmp r0, r3
blt second_stage
ldrh r3, [r5, #0xc]
bl time_calc
cmp r0, r3
blt third_stage
ldrh r3, [r5, #0x10]
bl time_calc
cmp r0, r3
blt fourth_stage
ldrh r3, [r5, #0x14]
bl time_calc
cmp r0, r3
blt last_stage
mov r0, #0xff /*over the last stage, error*/
pop {r3,r5, pc}
first_stage: mov r0, #0x1
pop {r3,r5, pc}
second_stage: mov r0, #0x2
pop {r3,r5, pc}
third_stage: mov r0, #0x3
pop {r3,r5, pc}
fourth_stage: mov r0, #0x4
pop {r3,r5, pc}
last_stage: mov r0, #0x5
pop {r3,r5, pc}
/*the small function that calculates what mulch was used.
made specifically for this batch of fucntions, doesn't work
if used outside of them*/
time_calc: ldrh r1, [r6]
lsl r1, r1, #0x11
lsr r1, r1, #0x1e
cmp r1, #0x1
beq half_time /*grows 2 times faster*/
cmp r1, #0x2
beq double_time /*takes double time to grow*/
mov pc, lr
half_time: lsr r3, r3, #0x1
mov pc, lr
double_time: lsl r3, r3, #0x1
mov pc, lr
/*a small function that loads the current time and stores it at the time variables.
receives r0 as the RTC loaction and r1 as the variable location. returns nothing.*/
replace_old_time: push {r4, r5, lr}
add r4, r0, #0x0
add r5, r1, #0x0
ldrb r1, [r4]
lsl r1, r1, #0x8
ldrb r0, [r4, #0x1]
orr r1, r0
lsl r1, r1, #0x8
ldrb r0, [r4, #0x3]
orr r1, r0
lsl r1, r1, #0x8
ldrb r0, [r4, #0x4]
orr r1, r0
str r1, [r5]
pop {r4, r5, pc}Finally, we need to be able to change the image of the OW. Some theories came to mind on how to do this one, but in the end I ended up with the following:
There is a limit of 256 different berry slots, each identified in the person id by the table number 0xfe. The game, when loading the OW, checks its table number, and in the same way Dynamic OWs were created, he also checks to see what it should print. It goes to the Plant variable, checks for the table index of that entry, calculates the current time on that variable to get its stage, and finally prints the corresponding OW. The code is as follows: (what matters in BOLD)
Code:
get_ow_addr: push {r2-r4}
lsl r1, r0, #0x10
lsr r1, r1, #0x18
lsl r0, r0, #0x18
lsr r0, r0, #0x18
ldr r4, new_ow_table
cmp r1, #0xff
beq special_decrypter
cmp r1, #0xfe
[B]beq berry_decrypter[/B]
more_check: cmp r1, #0xff
bgt go_old /*to allow for a multi-sized Table table*/
cmp r1, #0x0
bne end_check
cmp r0, #0xef
bgt go_old
bl multi_check
end_check: lsl r1, r1, #0x2
add r3, r4, r1
ldr r2, [r3]
cmp r2, #0x0
bne location_real
ldr r2, [r4]
location_real: lsl r0, r0, #0x2
add r3, r2, r0
ldr r0, [r3]
cmp r0, #0x0
bne end_ow_change
ldr r3, [r4]
add r3, #0x40
ldr r0, [r3]
end_ow_change: pop {r2-r4}
pop {r1}
bx r1
special_decrypter: cmp r0, #0xf /*change here for more variables usable*/
bgt more_check
ldr r1, var_4080
add r0, r1, r0
bl call_var_decrypt
ldrb r1, [r0, #0x1]
ldrb r0, [r0]
b end_check
[B]berry_decrypter: bl plant_ow_get /*see berry implementations*/[/B]
[B] b end_check[/B]
[B].hword 0x0000[/B]
new_ow_table: .word 0x0871bae0 /*0xffffffff*/
var_4080: .word 0x00004d00 /*0xffffffff*/
go_old: pop {r2-r4}
ldr r1, loader_call
bx r1
/*this is the check that allows for trainer OW switch
How it works: Vars 4054-59 must have a value. 0x0 for the
default sprite, 0xyyyy for the new sprite*/
multi_check: push {lr}
push {r0, r1}
cmp r0, #0xD
bgt no_change
cmp r0, #0x7
blt hero_change
sub r0, #0x7
hero_change: ldr r1, var_Hero
add r0, r0, r1
bl call_var_decrypt
b end_multi_check
no_change: pop {r0,r1}
pop {pc}
end_multi_check: ldrh r1, [r0]
cmp r1, #0x0
beq no_change
lsl r0, r1, #0x18
lsr r0, r0, #0x18
lsr r1, r1, #0x8
pop {r2,r3}
pop {pc}
.hword 0x0000
var_Hero: .word 0x00004054
loader_call: .word 0x0805f2d5
[B]plant_ow_get: push {r4-r7, lr}[/B]
[B] ldr r6, var_plant_time /*get plant spent time data*/[/B]
[B] add r6, r0, r6[/B]
[B] ldr r7, var_plant /*get plant data variable*/[/B]
[B] add r0, r0, r7[/B]
[B] bl call_var_decrypt[/B]
[B] add r7, r0, #0x0[/B]
[B] add r0, r6, #0x0[/B]
[B] bl call_var_decrypt[/B]
[B] add r6, r0, #0x0[/B]
[B] ldrh r0, [r7][/B]
[B] lsl r0, r0, #0x18[/B]
[B] lsr r0, r0, #0x18[/B]
[B] cmp r0, #0x0[/B]
[B] bne cont_tree[/B]
[B] mov r0, #0x0[/B]
[B] mov r1, #0x0[/B]
[B] pop {r4-r7, pc} [/B]
[B]cont_tree: ldr r5, berry_table[/B]
[B] mov r1, #0x18[/B]
[B] mul r0, r1[/B]
[B] add r5, r5, r0[/B]
[B] mov r2, #0x0[/B]
[B] ldrh r3, [r6][/B]
[B] ldrh r1, [r7][/B]
[B] lsl r1, r1, #0x11[/B]
[B] lsr r1, r1, #0x1e /*gets the mulch used*/[/B]
[B]tree_find_loop: add r5, #0x4[/B]
[B] ldrh r0, [r5][/B]
[B] bl time_calc [/B]
[B] cmp r3, r0[/B]
[B] ble ow_found[/B]
[B] add r2, #0x1[/B]
[B] cmp r2, #0x5[/B]
[B] blt tree_find_loop[/B]
[B] sub r3, r3, r0[/B]
[B] strh r3, [r6][/B]
[B] ldrh r1, [r7][/B]
[B] lsl r1, r1, #0x18[/B]
[B] lsr r1, r1, #0x18[/B]
[B] strh r1, [r7][/B]
[B] mov r1, #0x0[/B]
[B] sub r5, #0x14[/B]
[B] mov r2, #0x0[/B]
[B] b tree_find_loop[/B]
[B] pop {r4-r7,pc}[/B]
[B]ow_found: ldrb r1, [r5, #0x2][/B]
[B] ldrb r0, [r5, #0x3][/B]
[B] pop {r4-r7,pc}[/B]
[B]var_plant: .word 0x00007d00 /*your variables here*/[/B]
[B]var_plant_time: .word 0x00007e00[/B]
[B]berry_table: .word 0x090004e8 /*your berry table here*/[/B]
[B]time_calc: cmp r1, #0x1[/B]
[B] beq half_time /*grows 2 times faster*/[/B]
[B] cmp r1, #0x2[/B]
[B] beq double_time /*takes double time to grow*/[/B]
[B] mov pc, lr[/B]
[B]half_time: lsr r0, r0, #0x1[/B]
[B] mov pc, lr[/B]
[B]double_time: lsl r0, r0, #0x1[/B]
[B] mov pc, lr[/B]
call_var_decrypt: ldr r2, var_decrypt
bx r2
.hword 0x0000
var_decrypt: .word 0x0806E455Another problem present is how to keep the time the game was last updated. The out-game updating routine takes care of updating the time it was executed, but there was no need to save every minute. All we need is for the variable to be up-to-date as we save the game. So, I created this save hack that saves the variable when the save screen is shown:
Code:
/*if the game saved in the variables the new time all the time, the function would be
so time-consuming it could never run once every minute without noticeable delay. as such
the variables containing the time will only be saved when the Save game popup appears.
because it doesn't really matter that the variables are changed in game, only that they
have saved the last real time they were played on, the variables will write themselves each
time the save popup is called.
the easiset way to insert this function is to place it on the site of the save string, and
force it to go to the string display function afterwards. So
6f7c8 == bx r0 (00 47)
6f7d4 == pointer to this function
*/
replace_old_time: ldr r0, timer_var
bl call_var_decrypt
add r3, r0, #0x0
ldr r2, RTC
ldrb r1, [r2]
lsl r1, r1, #0x8
ldrb r0, [r2, #0x1]
orr r1, r0
lsl r1, r1, #0x8
ldrb r0, [r2, #0x3]
orr r1, r0
lsl r1, r1, #0x8
ldrb r0, [r2, #0x4]
orr r1, r0
str r1, [r3]
ldr r0, save_question
ldr r1, next_save_q
ldr r2, return_addr
mov lr, r2
ldr r2, copy_save_string
bx r2
timer_var: .word 0x00004090
RTC: .word 0x0300553f
save_question: .word 0x081c55c9
next_save_q: .word 0x0806f7dd
return_addr: .word 0x0806f7cf
copy_save_string: .word 0x0806f69d
call_var_decrypt: ldr r1, var_decrypt
bx r1
var_decrypt: .word 0x0806E455I finished a routine that gets the planted item, as well as the quantity produced. The formula to the number of items was previously mentioned, but there is a special case that when it's 0, it will give 2 if always watered and 1 otherwise. It uses variables 0x8004 and 0x8005, and returns to 0x8004 and to r0 the item and to 0x8005 returns the number of items. This code is supposed to be used with a callasm or included in an empty special.
Code:
/*this code does not remove the berry tree, or update any value. It simply checks.
*/
Get_berry: push {r4-r5, lr}
ldr r5, var_8004
ldrh r0, [r5]
mov r1, #0x40
lsl r1, r1, #0x8
cmp r0, r1 /*checks if r0 is a valid variable*/
blt end_now
bl call_var_decrypt
ldrh r4, [r0]
ldr r1, berry_table
lsl r0, r4, #0x18
lsr r0, r0, #0x18
mov r2, #0x18
mul r0, r2
add r1, r0, r1
ldrh r0, [r1] /*gets the item*/
strh r0, [r5] /*stores it at 0x8004*/
ldrb r0, [r1, #0x3] /*gets the min item value*/
lsl r2, r2, #0x13
lsr r2, r2, #0x18
cmp r0, #0x0
beq special_case
lsl r0, r2
store_num: strh r0, [r5, #0x2] /*number of berries stored at 0x8005*/
lsl r0, r4, #0x18
lsr r0, r0, #0x18 /*so it returns the berry number*/
end_now: pop {r4-r5, pc}
special_case: mov r0, #0x1 /*the special "0" case*/
cmp r2, #0x4
bne store_num
lsl r0, r0, #0x1
b store_num
var_8004: .word 0x020370c0
berry_table: .word 0x00000000 /*place table address here*/
call_var_decrypt: ldr r1, var_decrypt
bx r1
var_decrypt: .word 0x0806E455That's what I've got so far. To be a fully functional berry tree hack, it still needs the gets and sets of this type, that is:
planting routine;
add mulch routine;
watering routine;
Check tree state routine;
Check watered time routine;
Berry script.
So, before I leave, I have some questions I need to raise.
First, how do you thing the planting should be done? It's two simple setvars, one for the plant and one for the timer, but how will we find the item the player wants to plant, and its position on the table?
Second, do you think it would be more appropriate to change the OW hack to instead of reading of a variable, reading a set of variables concerning where it is? For instance, its not var sprite 0x0, table 0xfe = var 0x7d00 plant, but rather sprite 0x0, table 0xfe = a fixed variable that contains the plant variable. Having regional variables can increase the number of berries possible, but is it really necessary to have more than 256 berry plants? And if so, what would be a good number of variables to set apart for a map script to change?
Third, do you think the item number should be determined by the given formula, or would you prefer something more like the 0 case (the byte only represents a mode)?
Last edited: