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?

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.

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.

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!

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!

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.

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.

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?

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!

Sorry, but a straight up patch is a VERY bad idea because it might overwrite another hacker's hard worked on data. If I had the know how, I'd write a tool which inserts the routines in a sensible location for you, but I don't. Shiny Quagsire's tool is outdated and was designed for a much older version of the routine. AFAIK, he's working on updating it, and is trying to build the routine insertion into it.

EDIT: I patched the time update routine onto the main loop on Emerald by using this routine:

In order for this to work, go to 0x080004CA, and stick the following code in instead:
What this does is makes the time update routine be called once a frame no matter where in the game you are or what you are doing.

I actually had a version that worked, but when I tried to wipe my computer, the flash drive that had our backed up info died. Luckily I had the old source code lying around in my own flash drive, which had my hacking stuff, so I'm trying to back that up to the newer version.

This is just a suggestion that may make things more complicated than they may need to be, but here it is: Variable length of the days by season.

I'm suggesting it because I've lived in areas where daylight will last for about twenty hours during summer(Prince George, British Columbia, Canada), and it always felt like the cold would set in earlier and longer, with the nights lasting just as long during winter. I've also known people who've lived close enough to the equator that for most of their lives, they've only known one type of season, despite the calendar saying that its winter or spring. One thing that I've seen in the section "What makes a good ROM" is how realistic it is, and it would add a very realistic element to the game if it changed the length of the days for each season and changed the weather in the battle with each season (ex: if the climate was tropical, it would either be raining or sunny, likely with little to no variation on the length of days).

Granted, it may be a little to hard to do the coding for, so I can understand if this suggestion is overlooked for now.

Suggestion for how it could work if the idea is taken seriously: using something similar to the Header section of Advance Map, with the added option of Climate.

I'm not very good at coding, but I am good at testing. I'll take a look at the most recent version of the D/N program and test it on a spare ROM if somebody can send me the link for it.

Edit: Also posting the idea of length of days being able to change by season in the section entitled "Research: Seasons in Fire Red" started by Shiny Quagsire. This idea may also be more appropriate there.

Actually, that'd have to be done in the D/N system itself. This just makes pokemo vary from day to night.

I could however, slightly rewrite the coding to support differing Pokémon by season, but it just makes the already massive tables needed for just the day to night transition even bigger.

As for the actual on screen seasonal transition...? Not even my ASM, so wrong thread my friend.

On topic - Have you finished rewriting the tool shiny quagsire?

This seems awesome! :D
Well, with a tool it would make this function very common, although without a tool i wouldnt be able to use it (as of right now.. xD).

Good luck, I'll be following this thread! :3

ty I was very interested in this very much. you must be credited when I use this.

What's the purpose of the variable in the level loading routine?

I believe it's for swarming, but it seems that the code for that was moved to the other routine, so you could take the variable code out and save yourself a few bytes of freespace.

Awesome, thanks. I was looking, and thought "..."

Sorry about double posting, but where are the wild data pointers located? The example was about route 1, yet I have no idea where the other pointers are.

Sorry for TRIPLE posting, but I have yet to find out how this table is stored. I found a pointer to the wild data in route 1, yet the table it's aligned in seems awkward. Anyone have an explanation?