Development: Day/Night Switching of Wild Pokémon

[Shiny Quagsire]

Alrighty! I've finally finished DN Pokemon Data Editor! The download is in an attachment as a zip file. Keep in mind this is only in it's early versions, and may have a bug in it. If you find a bug, contact me by way of PM.

 

[destinedjagold]

So, is this research, and this new tool, can change the PKMN in the wild depending if it's day or night, just like in the 2nd generation of games?

 

[Shiny Quagsire]

So, is this research, and this new tool, can change the PKMN in the wild depending if it's day or night, just like in the 2nd generation of games?

Yup. And soon morning and evening, if everything goes along right.

 

[altariaking]

I have an idea for the tool. How about instead of having the Pokemons names listed alphabetically, have the names of Pokemon from the rom listed by their pokedex order? Because I inserted a fakemon over another Pokemon, and since it's name isn't there, I can't remember which Pokemon I replaced, and the Pokemon are listed alphabetically, it makes it hard to find :\

Edit: For some reason it freezes when I run into a wild Pokemon at night :\

 

[Sierraffinity]

I THOUGHT I had the offset for the time in Emerald! I looked through my notes, and here it is: 0x03005CFA.
The reason that you probably didn't find it is probably that it doesn't update unless you do special things, like entering a new map, using a command\special that causes the time to be reloaded, etc.

 

[Jambo51]

I THOUGHT I had the offset for the time in Emerald! I looked through my notes, and here it is: 0x03005CFA.
The reason that you probably didn't find it is probably that it doesn't update unless you do special things, like entering a new map, using a command\special that causes the time to be reloaded, etc.

Hmmm, seems really like it was built for efficiency rather than realism. I don't suppose there's any way we could use interdpth's FR RTC instead - Adapt it for use on Emerald. However, the routine I developed would be able to use it, it'd just not work properly because it'd be reading a static time which isn't updated until you leave the map.

 

[Darthatron]

Hmmm, seems really like it was built for efficiency rather than realism. I don't suppose there's any way we could use interdpth's FR RTC instead - Adapt it for use on Emerald. However, the routine I developed would be able to use it, it'd just not work properly because it'd be reading a static time which isn't updated until you leave the map.

Just put a write-breakpoint on that area of the RAM, and find the routine that updates it, then call it before a battle/your routine is initiated. Would that not work?

 

[Jambo51]

Just put a write-breakpoint on that area of the RAM, and find the routine that updates it, then call it before a battle/your routine is initiated. Would that not work?

Yes, that would work, but as colcolstyles posted before, the rtc only updates when the map is refreshed (i think) or when you change map. I'd have to add an extra part to my routine to make it work, assuming that it updates on refresh. Certainly doable, but a pain nonetheless.

 

[Darthatron]

Yes, that would work, but as colcolstyles posted before, the rtc only updates when the map is refreshed (i think) or when you change map. I'd have to add an extra part to my routine to make it work, assuming that it updates on refresh. Certainly doable, but a pain nonetheless.

Not JUST when a map is entered. If you find the routine that refreshes the time, then you could call it before your routine is used. Simple.

 

[Jambo51]

Not JUST when a map is entered. If you find the routine that refreshes the time, then you could call it before your routine is used. Simple.

Yeah, good point. Sorry, I don't know why I missed that before XD. Still, it's a lot of work for a rom i'll almost certainly never use myself.

 

[Sierraffinity]

Hey, Jambo51, I have another RTC address for Emerald you may or may not be interested in: 03000DC0. This one has years, day of the week, and other fun things... in binary-coded decimal, however. This means that the hex value that's there looks like is real decimal value.
Ex. 10:30 looks like 0x10 0x30.

 

[Jambo51]

Hey, Jambo51, I have another RTC address for Emerald you may or may not be interested in: 03000DC0. This one has years, day of the week, and other fun things... in binary-coded decimal, however. This means that the hex value that's there looks like is real decimal value.
Ex. 10:30 looks like 0x10 0x30.

Interestingly, this one is automatically updated every time I enter the battle screen. IF it's done before my battle routine, this could be the answer to the Day/Night Routine for emerald!

 

[Sierraffinity]

Interestingly, this one is automatically updated every time I enter the battle screen. IF it's done before my battle routine, this could be the answer to the Day/Night Routine for emerald!

I thought that you had already found the time updater, though.
Actually, it doesn't update upon entering battle. It's probably your call to the updater that's doing it.

 

[Jambo51]

I thought that you had already found the time updater, though.
Actually, it doesn't update upon entering battle. It's probably your call to the updater that's doing it.

It was indeed my call to the time updater routine which was updating it. I changed the ram offset for the hour byte in both routines, and modified the compare so that they would be in hex-decimal. The routine should work perfectly now! Thanks for the help!

 

[colcolstyles]

The thing with the data at '0x03000dc0' is that they aren't offset based on the time that the player input. The data there are just what the game reads from the RTC. The game later takes the time there and offsets it based on the player's input. For example, if the time on a player's computer is 9:00 but the player enters 10:00 during the clock-setting special, then the time at '0x03000dc0' will say 9:00 but the time at '0x03005cfa' will be 10:00.

 

[Jambo51]

The thing with the data at '0x03000dc0' is that they aren't offset based on the time that the player input. The data there are just what the game reads from the RTC. The game later takes the time there and offsets it based on the player's input. For example, if the time on a player's computer is 9:00 but the player enters 10:00 during the clock-setting special, then the time at '0x03000dc0' will say 9:00 but the time at '0x03005cfa' will be 10:00.

OK, thanks for letting me know that. I do have an idea to sort it though! What I plan to do is to store the "pre-update" time and the "post-update" time. I subtract the 2 to obtain the difference between the 2, then use that difference to update the main time! Does that make sense? A roundabout way of fixing it, but I haven't the will or knowledge to go digging around the ROM for the proper update routine. As both times would be updated at the same time, they would never be out of sync, allowing this idea to work.

 

[Shiny Quagsire]

The thing with the data at '0x03000dc0' is that they aren't offset based on the time that the player input. The data there are just what the game reads from the RTC. The game later takes the time there and offsets it based on the player's input. For example, if the time on a player's computer is 9:00 but the player enters 10:00 during the clock-setting special, then the time at '0x03000dc0' will say 9:00 but the time at '0x03005cfa' will be 10:00.

Theoretically, wouldn't the 0x03000dc0 offset be blank on an individual cart, or be set to the time of the other RTC? I'm probably wrong, but it's a possible answer. I don't think it'd be pre-set, because Japan and the USA have different time zones.

 

[colcolstyles]

Theoretically, wouldn't the 0x03000dc0 offset be blank on an individual cart, or be set to the time of the other RTC? I'm probably wrong, but it's a possible answer. I don't think it'd be pre-set, because Japan and the USA have different time zones.

I'm not sure what you're trying to say. Here, '0x03000dc0' is where the game writes the RTC data immediately after they are read from the RTC chip. When the game is being emulated on a PC, the time will be whatever time it is on the player's computer. If the game is on a game pak (with a RTC chip), then it just reads whatever the RTC gives it. Then, at a later time, the game reads the hour, minute, and second bytes from '0x03000dc0', converts them to hexadecimal, offsets them based on a value which is calculated when the player sets the clock in his/her room, and then stores the new values at '0x03005cfa'. At least, that's my understanding of it.

 

[Jambo51]

I'm not sure what you're trying to say. Here, '0x03000dc0' is where the game writes the RTC data immediately after they are read from the RTC chip. When the game is being emulated on a PC, the time will be whatever time it is on the player's computer. If the game is on a game pak (with a RTC chip), then it just reads whatever the RTC gives it. Then, at a later time, the game reads the hour, minute, and second bytes from '0x03000dc0', converts them to hexadecimal, offsets them based on a value which is calculated when the player sets the clock in his/her room, and then stores the new values at '0x03005cfa'. At least, that's my understanding of it.

What I'm meaning is that the time update routine I found (the one which updates 0x03000DC0) can be used to update the main one manually, as long as it's updated at the same time. What I would do is load the values of the RTC at 0x03000DC0 before updating into the registers, then update the time. Then calculate the difference in time between the pre-update time and the post update time. Then using that difference, update the time at the offset 0x03005CFA.

Does that make sense?

 

[Luiz Felipe Apolinário]

Jambo you have to do make a patch with your asm already inserted in the pokemon firered for me to test the tool's shiny Quagsire? If you can do it I would greatly appreciate it. Thank you for your attention!