Development: Berry system for Fire Red with RTC

[Shiny Quagsire]

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]

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.

Spoiler:

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]

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]

Do I have to hex edit and which portion of hex codes?

 

[NintendoBoyDX]

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]

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]

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]

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]

Thanks, so there are multiple places to store values near LASTRESULT?

 

[Jambo51]

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]

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]

Is there a video on how to do this, because it just flew over my head

 

[Shiny Quagsire]

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.