View Single Post
Old January 24th, 2010 (03:42 PM).
pokemon rom researcher
Join Date: Dec 2008
Quote originally posted by HackMew:
Just out of curiosity, what's the point of having SO much money? It would take ages just to reach that limit. I guess 999999 is a good amount IMHO.
In a normal pokemon game, the usual limit is perfectly good. But for some other types of hack, like simulator-based, the 1 million limit is reached pretty fast. Here, I think of projects that rely heavily on money to work, where you want the player to be rewarded by good money management, and where the player can produce items. An example would be a simulator based on a pokemon game, where real-estate purchases (buy a house, buy terrain) can easily overcome that limit.

Quote originally posted by HackMew:
Special editing may be limitative, but breaking commands compatibility is worser. Backward compatibility has already been broken (which is the main reason I don't like this hacked engine), basically. But that's not the point. Let's just not forget there's always callasm. Sure, it's not as comfy as specials, but I think I don't need to remind you that only FR/LG have many nopped specials. Yes, I do know it's called "Fire Red Hacked Engine". But porting it to other games it someday is always a possibility that should at least be considered.
In this case, I partially agree with you. One of the things I tried the hardest is to reduce the changes in-game, in order to keep the old game systems and functions working as they were intended. That is why I always search around for unused bytes on structures in the game to place them on. The sethealingplace one also annoys me a bit, so I made a few fixes and now mimic the old code if no values are placed in the variables. Next release should fix it. If you know of any other that messes things the old game should do, feel free to tell me so I can fix it.
Lastly, about the specials, I used these in order to simplify usage. The main objective of this hack is to provide a number of new features with simplicity of use. The main reason I try to mantain retro-compatibility is so that anyone who uses this hack doesn't need to learn new info that conflicts with the original games, and so that we can use the good tools out there we used to use.

Quote originally posted by Deokishisu:
And for the suggestion, now that a RTC has been implemented into FR successfully, it may be time to step it up on the berry front. My suggestion is to add the R/S/E berry system into your engine, utilizing the RTC by interdepth and ZodiacTheGreat. The growing cycles for each berry can be found on each berry's individual Bulbapedia page, along with other miscellaneous information you may need regarding how it should turn out.

And here's a totally outlandish one that I personally wouldn't really need, and would probably take insane amounts of work that I really don't want to put you through, but might be something to keep in mind. Pokemon Contests from R/S/E? I just thought people might want that ported to FR. I don't really care either way, but it's something to consider.
Actually, the only reason I didn't implement a berry growth system yet is because of three simple things.
First, I have no way to display the berry trees in their growth stage. Berry trees aren't typical sprites, so there is no way to simply copy them and paste them on a new OW table. And I have near zero graphical skills, so creating berry trees from scratch would be nigh impossible.
Second, the in-game costs. You would need a variable for each berry patch, plus one other variable for all the data relating to current growth time, growth stage... I've made some studies in this matter, and could get 256 berry patches in the same way as the Dynamic OW switches, by using a compressed data system that would use the last 6 or 7 bits of the variable contents as the entry in that table (as there are less than 63 berries, if you want up to 127 berries, the growth time had to be sacrificed). And would require a secondary data table, to keep all the growth time tables, types of berries, and other data.
Third, I don't really believe in the RTC mechanics. I appreciate the work made by interdepth, as i checked it out and it's quite good, but I always disliked the fact you had to play at a certain time to work with it. Also, I would have no way to test anything with RTC, as my computer seems to hate it, and wouldn't have the time to make a full debugging of that function.

So, following all these reasons, I must say, if problem number one was fixed, I could probably go around the other two. Myself, I would prefer a simulated time system rather than a real one, and would more easily implement one and use it.

As for the second suggestion, porting the Contest system from R\S\E onto Fire Red would be really hard. Not only would it be necessary to know where all data related to the contests was, as well as routines, you would also need to find out which pointers to routines are also present in Fire Red (like the OW Map function), which to keep, which to change, and finally, after all that, we would need to repoint the data stored in the RAM so it doesn't overwrite the used by Fire Red. The amount of work required for that one would be so great, it would probably be best to remake it from scratch. So this one I might state that will not be ported to Fire Red.
Here are the links for my work

Currently working on:
Battle Script Documentation
Another large project
Reply With Quote