PDA

View Full Version : Berry system for Fire Red with RTC


JPAN
February 15th, 2010, 10:28 PM
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):
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
Second Variable - Plant timer
2 bytes time passedThis 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:
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 ripeThis 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):
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|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.
/*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

add_var_routine: ldr r1, last_time
ldrb r0, [r1]
cmp r0, #0x0 /*if timer is 0, nothing to do yet*/
beq end_this
sub r0, #0x1
ldr r2, timer_min
ldrb r2, [r2]
cmp r2, r0
beq end_this

timer_update: add r2, #0x1
strb r2, [r1]
push {r4-r7, lr}
ldr r7, var_plant
ldr r6, var_plant_time
mov r5, #0xff
ldr r4, berry_table

timer_up_loop: add r0, r7, #0x0
bl call_var_decrypt
ldrh r1, [r0]
cmp r1, #0x0
beq next_plant
bl time_and_water

next_plant: sub r5, #0x1
add r7, #0x1
add r6, #0x1
cmp r5, #0x0
bge timer_up_loop
pop {r4-r7,pc}

end_this: mov pc, lr

.hword 0x0000
var_plant: .word 0x00007d00 /*intput your plant variables here*/
var_plant_time: .word 0x00007e00
last_time: .word 0x0203f3f0
timer_min: .word 0x03005543
berry_table: .word 0x00000000 /*replace by your table*/

/*this function will up the timer and allow you to water again after the plant has supposedly grown. this function is completely dependant on the above one*/
time_and_water: push {r6,r7,lr}
add r7, r0, #0x0
add r0, r6, #0x0
push {r1}
bl call_var_decrypt
pop {r1}
add r6, r0, #0x0
ldrh r2, [r0]
add r2, #0x1
strh r2, [r0] /*stores the value first, to avoid problems*/
lsl r3, r1, #0x18
lsr r3, r3, #0x18
mov r0, #0x18
mul r3, r0
add r3, r4, r3
bl time_ops
ldrh r0, [r3, #0x4]
cmp r0, r2
beq water_able
ldrh r0, [r3, #0x8]
cmp r0, r2
beq water_able
ldrh r0, [r3, #0xc]
cmp r0, r2
beq water_able
ldrh r0, [r3, #0x10]
cmp r0, r2
beq water_able
ldrh r0, [r3, #0x14]
cmp r2, r0
bge dispose_of
pop {r6,r7,pc}

water_able: lsl r1, r1, #0x11
lsr r1, r1, #0x11 /*eliminates watered byte*/
strh r1, [r7]
pop {r6,r7,pc}

dispose_of: lsl r1, r1, #0x18
lsr r1, r1, #0x18
strh r1, [r7] /*eliminates the old care bits*/
sub r2, r2, r0
str r2, [r6] /*places 0 on the old spot.*/
pop {r6,r7,pc}


call_var_decrypt: ldr r1, var_decrypt
bx r1
var_decrypt: .word 0x0806E455

/*calculates the time appling the mulch effect*/

time_ops: lsl r0, r1, #0x11
lsr r0, r0, #0x1e
cmp r0, #0x1
beq half_time /*grows 2 times faster*/
cmp r0, #0x2
beq double_time /*takes double time to grow*/
mov pc, lr
half_time: lsr r2, r2, #0x1
mov pc, lr
double_time: lsl r2, r2, #0x1
mov pc, lr

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
/*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)
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
beq berry_decrypter
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
berry_decrypter: bl plant_ow_get /*see berry implementations*/
b end_check
.hword 0x0000
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

plant_ow_get: push {r4-r7, lr}
ldr r6, var_plant_time /*get plant spent time data*/
add r6, r0, r6
ldr r7, var_plant /*get plant data variable*/
add r0, r0, r7
bl call_var_decrypt
add r7, r0, #0x0
add r0, r6, #0x0
bl call_var_decrypt
add r6, r0, #0x0
ldrh r0, [r7]
lsl r0, r0, #0x18
lsr r0, r0, #0x18
cmp r0, #0x0
bne cont_tree
mov r0, #0x0
mov r1, #0x0
pop {r4-r7, pc}

cont_tree: ldr r5, berry_table
mov r1, #0x18
mul r0, r1
add r5, r5, r0
mov r2, #0x0
ldrh r3, [r6]
ldrh r1, [r7]
lsl r1, r1, #0x11
lsr r1, r1, #0x1e /*gets the mulch used*/

tree_find_loop: add r5, #0x4
ldrh r0, [r5]
bl time_calc
cmp r3, r0
ble ow_found
add r2, #0x1
cmp r2, #0x5
blt tree_find_loop

sub r3, r3, r0
strh r3, [r6]
ldrh r1, [r7]
lsl r1, r1, #0x18
lsr r1, r1, #0x18
strh r1, [r7]
mov r1, #0x0
sub r5, #0x14
mov r2, #0x0
b tree_find_loop
pop {r4-r7,pc}

ow_found: ldrb r1, [r5, #0x2]
ldrb r0, [r5, #0x3]
pop {r4-r7,pc}

var_plant: .word 0x00007d00 /*your variables here*/
var_plant_time: .word 0x00007e00
berry_table: .word 0x090004e8 /*your berry table here*/

time_calc: 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 r0, r0, #0x1
mov pc, lr
double_time: lsl r0, r0, #0x1
mov pc, lr

call_var_decrypt: ldr r2, var_decrypt
bx r2
.hword 0x0000
var_decrypt: .word 0x0806E455This 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:
/*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 0x0806E455
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.
/*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 0x0806E455

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)?

NarutoActor
February 16th, 2010, 04:28 PM
Wow, great job I had to read it twice to fully understand. :P But on your questions do you think it is possible to make a routine that when they click on the dirt path, you then they can click on a berry you want to plant, and the berry chosen gets placed into a var. Then the other routine checks the var.

Or make a routine kinda similar to the special the makes the player chose 3 pokemon, but insted of choosing 3 pokemon you chose one berry.

helloNL
February 17th, 2010, 10:21 AM
how to install this?
i dont see how

Tropical Sunlight
February 17th, 2010, 10:51 AM
how to install this?
i dont see how
You "install" this with an ASM... thing.

NarutoActor
February 17th, 2010, 12:50 PM
Some routines should be complied with gas, or goldroad while others should be complied with devkitpro. He specified what code was in devkitpro. Once it is complied you have the hex code.

helloNL
February 18th, 2010, 09:55 AM
maybe someone make a ips?
or aps?

NarutoActor
February 18th, 2010, 01:04 PM
I would much more prefer to see this implemented into jpans program, if not keep it like this. Anybody can apply an ips patch, this way makes it so that only the decent hackers can reap the benefits.

colcolstyles
February 18th, 2010, 07:35 PM
I would much more prefer to see this implemented into jpans program, if not keep it like this. Anybody can apply an ips patch, this way makes it so that only the decent hackers can reap the benefits.

That's a pretty elitist outlook on knowledge. For me, one of the core aspects of ROM Hacking is the sharing of discoveries with other members of the community. Why should we exclude hackers from "reaping the benefits" of this very useful code?

And before you even think about, please don't pull the "it'll get overused and make it less special" argument. I saw that a lot with the release of Mastermind_X's Day/Night System and I'm getting pretty sick of it.

ZodiacDaGreat
February 18th, 2010, 08:53 PM
That's a pretty elitist outlook on knowledge. For me, one of the core aspects of ROM Hacking is the sharing of discoveries with other members of the community. Why should we exclude hackers from "reaping the benefits" of this very useful code?

And before you even think about, please don't pull the "it'll get overused and make it less special" argument. I saw that a lot with the release of Mastermind_X's Day/Night System and I'm getting pretty sick of it.
Yes, I agree knowledge should be shared and people who use the code must give credit - even if they temper with it and make a completely new code from it.

If something's overused or less special, then work hard and pull of something even better than the existing version of a cool hack. Otherwise don't complain ^^

helloNL
February 19th, 2010, 05:20 AM
its just that i never understand what JPAN is explaining
and i hack already a long time

Nodddy
February 19th, 2010, 09:43 AM
That's a pretty elitist outlook on knowledge. For me, one of the core aspects of ROM Hacking is the sharing of discoveries with other members of the community. Why should we exclude hackers from "reaping the benefits" of this very useful code?

And before you even think about, please don't pull the "it'll get overused and make it less special" argument. I saw that a lot with the release of Mastermind_X's Day/Night System and I'm getting pretty sick of it.Are you saying that he isn't sharing his work? Because if not I'd sure like to know what was in that huge first post he made.

Anyone who understands the information he has given is able to implement this in their own hack, and those who don't should learn what it means instead of blindly patching their ROM.

helloNL
February 19th, 2010, 10:14 AM
no
he was reacting to someone elses post
he wants that ppl share their discoveries

NarutoActor
February 19th, 2010, 12:59 PM
There not discovering anything throw a patch or learning anything. They will just be using the system for them self. It wouldn't be knowledge it would just be a new feature for them.

colcolstyles
February 20th, 2010, 04:36 PM
There not discovering anything throw a patch or learning anything. They will just be using the system for them self. It wouldn't be knowledge it would just be a new feature for them.

Clearly you misinterpreted what I said. I said nothing about whether using a patch is a discovery or not. My point was that if someone makes a discovery, it should be shared with the entire community. No one should be excluded based on how long they've been hacking or how "good" they are at hacking.

NarutoActor
February 20th, 2010, 08:43 PM
Well then you most of miss understood me. I am all for sharing discoveries, I don't care how long you hack, but I like it when discoveries are not just patches; because then you actually learn something.

Full Metal
February 20th, 2010, 09:32 PM
>__< in other words u two are saying the same thing
colcolstyles wants things to be open to everyone, and narutoactor wants it to be available to those who know how to use it, stop fighting about stupid stuff >__>
anyways, really liken this interdepth xD before long u are prob gonna have the entire ROM hacked xD

Darthatron
February 20th, 2010, 11:49 PM
I don't think you should make a patch, people should know how something works before they attempt to put it in their hack. It will just create more problems later.

>__< in other words u two are saying the same thing
colcolstyles wants things to be open to everyone, and narutoactor wants it to be available to those who know how to use it, stop fighting about stupid stuff >__>
anyways, really liken this interdepth xD before long u are prob gonna have the entire ROM hacked xD
This is JPAN, not interdpth. :\

ZodiacDaGreat
February 21st, 2010, 12:01 AM
I don't think you should make a patch, people should know how something works before they attempt to put it in their hack. It will just create more problems later.
Yeah which in turn leads to more PMs and more "How do Is", etc

Darthatron
February 21st, 2010, 12:08 AM
Yeah which in turn leads to more PMs and more "How do Is", etc

Yeah... I get enough of them already... Ones that have absolutely nothing to do with me what-so-ever - "How do you set IVs in YAPE", for example. Anyway... There will probably be a few posts saying "How do I insert this into my hack?" anyway... I don't know... JPAN can do whatever he likes.

Full Metal
February 21st, 2010, 12:25 AM
I don't think you should make a patch, people should know how something works before they attempt to put it in their hack. It will just create more problems later.


This is JPAN, not interdpth. :\
lol, i forgot they weren't the same (i thought interdepth was JPAN on another forum :P)

Shiny Quagsire
August 28th, 2010, 06:19 PM
I'm pretty sure the revival limit doesn't apply here...

OK, so I've followed through on this tutorial, inserted all of the routines and such, I've even written a water checker, waterer, and mulch adders. But, how exactly does the game know which overworld is a tree? Is it the person ID that's set to the variable? Or is it something different?

jakerman999
August 29th, 2010, 01:48 PM
Yo, JPAN, don't know if you got all the info you wanted from this thread(esp. with all the offtopic) and have carried on development, but thought I would throw in my two cents.

Planting berries could be done two ways that I can see. The first would be writing a routine from the use option in the item menu(checking if you're standing in front of a dirt patch, if not goto the regular berry use) which seems difficult as to my knowledge items are not completely understood yet. The second would be using a special command to select a berry(either by going to the item menu or your dynamic listboxes).

Your second question is worded somewhat ambiguously, so I'll answer both options. 256 is more than enough for types of berry plants. You might want to go up 1000(1024?) for number of berry plants that can be placed around the world map.

By your third question, I assume you mean number of berries received? I would just use a random number generator between 2 and 6. Saves space and time.

One more thought I had when reading your work was how you saved and recalled time. Your solution works, but it looks like a lot of effort only to fail if there is a one year gap, or February 29th pops up. My suggestion to this point is to store time in minutes and calculate the rtc value in minutes. It would save space both in asm code and in variables(one year in minutes can be expressed in twenty bits), won't break on February 29th and fixes the one year exploit/loophole/glitch/whatever.

And to everyone arguing about releasing this in a patch,see this spoilered rant.
Releasing this in a patch is a horrible idea. It relies on to other hacks for it to work, so it would have to be packaged with those hacks, bringing out a higher probability of something going wrong. The day night hack with the RTC isn't even JPAN's work so that's less of a reason make a patch for it. All of his work is sitting in the first post for anyone who wants to use it. Releasing a tool for it, or bundling it with the hacked engine is a MAYBE if the process could be automated, and IF JPAN wants to spend the time on it. Both unlikely.

Also, JPAN didn't discover anything to share, this was all created from scratch. Anyone could implement the final project with just a little bit of research and hardwork. If someone isn't willing to do that then they don't really need this in their project. This has remarkable documentation and I understood most of it first time through. Difficult to create from scratch? Very. Difficult to copy and implement? Not so much.

Shiny Quagsire
August 29th, 2010, 02:43 PM
Man, how come whenever I ask a question, I always answer it myself? (I was pretty sleepy last night doing this, maybe that's why...)
Anyways, I found my answer.

There is a limit of 256 different berry slots, each identified in the person id by the table number 0xfe.

So I set the overworld sprite # to 0xFE, and the person ID to the variable!

dt200
November 16th, 2010, 10:03 PM
Do I have to hex edit and which portion of hex codes?

NintendoBoyDX
December 31st, 2010, 04:56 PM
Sorry to resurrect an old topic, but I needed to ask, is there a way to get the time of the RTC clock? If so it would be pretty easily to script the entire GSC berry system(no planting/watering or moving icons involved, just pick a tree OW sprite, and give it a script to check the time, and if so use the giveitem command to give the person a berry once per day.

Jambo51
January 1st, 2011, 02:35 AM
Sorry to resurrect an old topic, but I needed to ask, is there a way to get the time of the RTC clock? If so it would be pretty easily to script the entire GSC berry system(no planting/watering or moving icons involved, just pick a tree OW sprite, and give it a script to check the time, and if so use the giveitem command to give the person a berry once per day.

In a script, simply put the following command:

copybyte 0x020370D0 0x03005542

That'll copy the hour byte of the RTC to the Lastresult variable for you to use.
Although JPAN's system would be better IMO, so you should at least consider it.

NintendoBoyDX
January 1st, 2011, 11:34 AM
Thanks, is there also a way to copy the contents of the day/month/year as well? I'm assuming that hours uses 0x9 for 9am and 0x15 for 9pm? Also is there a way to check if the lastresult
contents are greater or less than instead of equal or not equal to?

Jambo51
January 1st, 2011, 02:43 PM
Thanks, is there also a way to copy the contents of the day/month/year as well? I'm assuming that hours uses 0x9 for 9am and 0x15 for 9pm? Also is there a way to check if the lastresult
contents are greater or less than instead of equal or not equal to?

Yes, 0x9 is 9AM and 0x15 is 9PM.
Day of Month: 0x03005540
Day of Week: 0x03005541
Month: 0x0300553F

There is no way to call the year in the same fashion as it is a half word, rather than a byte. You would have to write a small asm routine to write it to a variable or something. For reference, add or subtract 2 to the lastresult ram pointer to change it to a preceding or following variable.

I forget the exact numbers which in a script indicate greater than or less than, but, if you're using XSE, you can simply do this instead, and XSE replaces it upon compile:

compare LASTRESULT 0x9
if B_>= call/goto @wherever

Upon compile to the rom, XSE replaces it with the relevant value, so it's not a problem. Isn't HackMew's tool wonderful? XD

NintendoBoyDX
January 1st, 2011, 07:13 PM
Thanks, so there are multiple places to store values near LASTRESULT?

Jambo51
January 2nd, 2011, 03:46 AM
Thanks, so there are multiple places to store values near LASTRESULT?

All of the 0x80XX family of variables are static, unlike the DMA protected majority (they move around the ram constantly), so anything from 0x8000 to 0x8013 will work with that formula. However, DO NOT USE 0x800F as it is the LASTTALKED variable, and is important for various other background routines. Other than that, you should be safe.

LASTRESULT = 0x800D in case you didn't know.

NintendoBoyDX
January 2nd, 2011, 12:47 PM
Got to be careful on that though jpan uses some of the variables for his hacked engine. Quick question about 0x80xx variables, are 0x8014 through 0x80ff static? If so why wouldn't they work in the same way as 0x8000 through 0x8013?

xephos
January 22nd, 2012, 08:53 AM
Is there a video on how to do this, because it just flew over my head

Shiny Quagsire
January 22nd, 2012, 09:25 AM
Nope. There isn't a patch either. I can honestly say that it took me weeks to get this to fully work, including custom ASM. I even hacked the berry bag so I could choose a berry from there. I'll have to upload a video sometime. Maybe a tutorial for that part.