Pokémon Fire Red Hacked Engine

[diegoisawesome]

Originally Posted by HackMew

Backward compatibility has already been broken (which is the main reason I don't like this hacked engine), basically.

HackMew, just out of curiosity, what do you mean by "backwards compatibility"?
And, to JPAN, I think that the new way would probably be more confusing than the current way, so just keep it as-is.

P.S. Using the hack tool, should I redo inserting all commands, or just insert the new ones? Or should I simply use the patch?
[BTW, you should start using HackMew's new tool, A-Ptch, as it has backwards patching compatibility.

[HackMew]

Originally Posted by diegoisawesome

HackMew, just out of curiosity, what do you mean by "backwards compatibility"?

I'll give you a little example: the sethealingplace command. In the hacked engine, it has changed and now requires three variables to be set in order to work properly.

[diegoisawesome]

Originally Posted by HackMew

I'll give you a little example: the sethealingplace command. In the hacked engine, it has changed and now requires three variables to be set in order to work properly.

Oh, so you meant "script backwards compatiblility, as scripts from the old/new couldn't go on to the new/old"? I see.

[HackMew]

Originally Posted by diegoisawesome

Oh, so you meant "script backwards compatiblility, as scripts from the old/new couldn't go on to the new/old"? I see.

That was just an example. Backward compatibility is anything about structures, specials, scripting commands etc. etc. For example, when I implemented the D/P evolutions in a FR ROM, I did not change the original structure on purpose (as Eevee gained 2 evolutions, the old structure would not have been enough, theoretically) and used a workaround just for Eevee.

[diegoisawesome]

Ah, I see.
Also, I sent you a PM which would have been off-topic here. Check your inbox.

[Deokishisu]

Hey JPAN, just thought I'd stop by again and give you some feedback and two suggestions for the next release.

I also think you should leave that the way it is. It's more complicated, and the current way works fine imo.

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.

[JPAN]

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.

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.

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.

[Deokishisu]

Originally Posted by JPAN

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.

I completely understand the contest thing. I just thought that if it was possible to do it without turning someone into a mindless hacking zombie in the process, you would know how! :P

About the graphical berry problem. I'm not exactly sure what you're saying there. Do you mean that their is literally no way to make a reasonably plausible sprite transition between the berry growth stages in Firered? That you wouldn't be able to link each berry to its respective tree sprite? You can't think of a way to show the intermediary sprite stages in berry growth but can only figure a way to show one or two? You can't find the different growth stage sprites so you can insert them? Please elaborate a bit, maybe we'd be able to work something out! Even a cheap workaround, or a skeleton that could be expanded upon later would be better than nothing imo.

EDIT: Oh, and another Hoenn related suggestion that I forgot. Emerald made several additions to ability and berry functionality, namely Flame Body and Magma Armor reducing the time it takes for a Pokemon to hatch, the EV reduction berries, and several other abilities receiving overworld effects. I was wondering if this too could be ported to your engine. When it comes to this, I have no idea how much work would be involved, but if you think it could be done, I'd be happy to grab a list of the changes and additions made in Emerald for you.

[JPAN]

Originally Posted by Deokishisu

About the graphical berry problem. I'm not exactly sure what you're saying there. Do you mean that their is literally no way to make a reasonably plausible sprite transition between the berry growth stages in Firered? That you wouldn't be able to link each berry to its respective tree sprite? You can't think of a way to show the intermediary sprite stages in berry growth but can only figure a way to show one or two? You can't find the different growth stage sprites so you can insert them? Please elaborate a bit, maybe we'd be able to work something out! Even a cheap workaround, or a skeleton that could be expanded upon later would be better than nothing imo.

Well, let me first explain what would be needed to create a Berry system. Consider this:

1st - Consider berry trees animated OWs:
If we notice, sprout and seed stages are common to all berries, so we can make the OW manager fetch those when the berry isn't ready. For the growing and ripe stages, we can use two sequential OW's. If we have a single table for all those OW's, we can have different berry trees for 127 different berries, which is more than there are berries. So, using a OW table for berries only, we could easily have that many trees, and that many berries available.

2nd - If berries are OWs that can appear anywhere, they are Dynamic OW's
Made it once, could make it again. Adding a new table of Dynamic OW's would be easy. I would propose that byte 0xFE in the OW loader would make it look in a separate set of variables, checking for the variable corresponding to the berry planting location. Berry planting locations are identified by the picture number, making them limited to 256 patches, same way the Dynamic OW's work now.

3rd - Lets consider Berries separate from OWs. Berries have data.
That's what Gamefreak did. It considered normal OWs were different from Berry trees, and that is why berries can't be translated directly from Ruby to Fire Red. And it's a good idea, anyway. We could attribute every berry a number (starting with 0x1 for cheri berry and ending in 0x2b for Enigma berry) and create a data table for each berry. That table could be simply this:

BERRY TABLE
2 bytes item number
2 bytes OW image
1 byte growth time seed-stage 1
1 byte growth time stage1 - stage 2
1 byte growth time stage2 - ripe
1 byte max time ripe-seed

Of course the table could be much more complex, but this would be enough.
So, in that Dynamic OW variables, we could keep data related to the berry itself and not the OW, as the OW function could fetch the real image to display from this table.
Instead, that Variable would keep this

BERRY VARIABLE
6 bits Table Index
2 bits growth stage
2 bits watered times
6 bits growth time

Where watered only counts once per stage, growth time is the time passed from last renewal (full cycle) and it's count in the minimum time unit for berries (with real time, I think that's 6 hours).
And as such, it would be possible to implement a very simple berry system in Fire Red.

Now, the actual answer to your question. What I was talking about in that post was my own limitations, and not the game's. As you may see (or not) from this post, I've spent a great deal of time trying to figure out how to put the berries in the game, and minimize needed data in Variable count.
The problem is not data handling, or routine creation. The problem is that there is no Image data for me to copy from one game to the other. While I could create a well-oiled system, without sprites to show, it would look bad. As I have no sprites to include, nor am I capable of making my own, I can't complete this project.

So, In a short sentence, as I have no Spriting skills, and there aren't any ready-made sprites to use, I can't complete this.

On a separate sidenote, one of the hacks I started out making relied heavily on this system, but on a more elaborate note. There, the berry tree data had about 32 bytes of data, counting with diferent variations such weather and seasons. But was halted indefinitely as the Images needed weren't arround.

Originally Posted by Deokishisu

EDIT: Oh, and another Hoenn related suggestion that I forgot. Emerald made several additions to ability and berry functionality, namely Flame Body and Magma Armor reducing the time it takes for a Pokemon to hatch, the EV reduction berries, and several other abilities receiving overworld effects. I was wondering if this too could be ported to your engine. When it comes to this, I have no idea how much work would be involved, but if you think it could be done, I'd be happy to grab a list of the changes and additions made in Emerald for you.

That falls under the Item and Ability hacking. The berries could be mimicked easily, as We've already came to the conclusion on how to use items in the bag, in the pokemon menu and in the Overworld. As for the abilities, I've started studying how the Battle screen is organized briefly, but other matters appeared, and I dropped it. Both Attack effects and Ability effects are not very studied areas, but Flame body and Magma Armor ability to hatch eggs could be applied as we know how to check for abilities and where the hatching routine is placed, as well as some other effects (don't remember the ability name) that acts as a natural repel and the one that makes lower-leveled pokemon appear. It can be done, but without ever trying to read into abilities in-batle, i can't say how much work it would take.

[iTeruri]

Thanks for the explanation on the item hack. I got it to work, however when you register the item (it's a key item) and use select to use the item, the screen keeps flashing and the rest of the game is frozen (you can't do anything).

[Full Metal]

uh...the guide fully explained how to change the OW of the player, but what i would like to know is how to use different pallettes for the male/female character? For me, changing the pallette of one changes the pallette of the other, is the ability to not do that available with your engine and i just missed it?

[sky_queen3]

Er, does 1.1 have a manual, I can't seem to find it.

Never mind, I found it. :cer_love:

[Darthatron]

Originally Posted by Full Metal

uh...the guide fully explained how to change the OW of the player, but what i would like to know is how to use different pallettes for the male/female character? For me, changing the pallette of one changes the pallette of the other, is the ability to not do that available with your engine and i just missed it?

Change the palette number and then edit it.

[Deokishisu]

Originally Posted by JPAN

The problem is that there is no Image data for me to copy from one game to the other. While I could create a well-oiled system, without sprites to show, it would look bad. As I have no sprites to include, nor am I capable of making my own, I can't complete this project.

So, In a short sentence, as I have no Spriting skills, and there aren't any ready-made sprites to use, I can't complete this.

Spoiler:

^Berry tree sprites. I think they're from D/P but number 43 is the last berry in the third generation, the Enigma Berry.

Oh, one more thing. Maybe a hatch egg command? Could be useful for a very expensive incubator type script. And just a quick question, it's prolly what I'm thinking, but I just want to make sure. All the commands regarding encrypting and decrypting the selected Pokemon work on eggs right? I can modify an egg's IVs and such just like any other Pokemon right?

[JPAN]

Originally Posted by iTeruri

Thanks for the explanation on the item hack. I got it to work, however when you register the item (it's a key item) and use select to use the item, the screen keeps flashing and the rest of the game is frozen (you can't do anything).

That is because the Item scripting routine was prepared for most hacked items, and not key items registered in select. The difference being one need to take you out of the bag, the other doesn't. For the first case (normal "use" press), you needed to get out of the bag, and so it does. In the second ("select" press), the routine will try to exit the bag for you, and as you aren't in a bag, that causes a large mess. It would be easy, then, to fix it: remove the bag-exit. So, we come to two solutions here. either a new, separate function for key items, or a single function for both normal and key-pressed items. I vote for the second, as all it would take would be adding a "if not OW, call bag exit" type of code.

Originally Posted by Full Metal

uh...the guide fully explained how to change the OW of the player, but what i would like to know is how to use different pallettes for the male/female character? For me, changing the pallette of one changes the pallette of the other, is the ability to not do that available with your engine and i just missed it?

This question covers many aspects of OW hacking. Let's assume a palette A for the hero, and B for the heroine. Both the heroine's and hero' s Slot is, by default, 0. If you try and change the sprite from the hero to the heroine one, when the sprite is finally loaded, the palettes should have been replaced, and no harm visible. Just remember that lots of icons use palette slot 0 as their color default (the pop-up ! box comes to mind), so make sure the edits don't turn it into something hideous.
Now, we assume we have both OW's (male and female) in the scene at once. As the palette slot is the same for them both, the one loaded first will be your player, and the second the opposite gender normal OW (your OW is always loaded first). As the second sprite is loaded last, it's its palette that is loaded in the screen, and your hero changes colors. This is not a byproduct of the hack, or anything like this, but rather a wrong configuration of the OW data. Simply change the OW slot to keep them both in their original colors.

Originally Posted by Deokishisu

Oh, one more thing. Maybe a hatch egg command? Could be useful for a very expensive incubator type script. And just a quick question, it's prolly what I'm thinking, but I just want to make sure. All the commands regarding encrypting and decrypting the selected Pokemon work on eggs right? I can modify an egg's IVs and such just like any other Pokemon right?

First of all, thanks for the sprites. After I insert them, I should be able to complete a rudimentar berry system. It will take a while, though.
As for the egg hatch command, check special 0xc1(no animation hatch) and 0xc2 (normal hatch routine). And yes, an egg is a normal pokemon, only one that has the egg flag set in the miscelaneous data. As such, any of the pokemon editing specials will affect eggs (and, suprisingly enough, even healt and pp related ones, leading to stuff like fainted eggs that can't be healed)

[Deokishisu]

Originally Posted by JPAN

First of all, thanks for the sprites. After I insert them, I should be able to complete a rudimentar berry system. It will take a while, though.
As for the egg hatch command, check special 0xc1(no animation hatch) and 0xc2 (normal hatch routine). And yes, an egg is a normal pokemon, only one that has the egg flag set in the miscelaneous data. As such, any of the pokemon editing specials will affect eggs (and, suprisingly enough, even healt and pp related ones, leading to stuff like fainted eggs that can't be healed)

Thanks for clearing up the egg crap for me. I thought as much.

Oh, and when you do have your epicly-awesome berry system down, make sure to make a detailed how-to in the next manual. I ended up not fully comprehending everything you said regarding how it would be implemented and carried out in game, and I'd hate to have to plague you with questions when the next version comes out. :P And take your time! Slow and steady wins the... hack?

<Insert generic your awesome keep up the good work comment here.>

[interdpth]

Originally Posted by JPAN

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.


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.


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.

Questions(also rant
1.Play at a certain time?
2.Use VBA-M or No$gba to use the engine to it's max.
The prior VBA's suck at RTC
3.There's an offset in my thread which tells what vars to set time with, it' just the matter of the hacker making a time setting function
4.ONLY ONE E >:(

[psychicboy]

Alright JPAN or anyone else who can help me. Could you give me a detailed example of how the set healing place works? I looked at the manual and tried it out as a script and it simply would not work.. I'm just so confused.

[Deokishisu]

Originally Posted by psychicboy

Alright JPAN or anyone else who can help me. Could you give me a detailed example of how the set healing place works? I looked at the manual and tried it out as a script and it simply would not work.. I'm just so confused.

Sethealingplace, I had trouble with it too.

#org @start
sethealingplace 0x0 **Regular Pokemon Center Healing Place**
setvar 0x405A 0x50C **Map bank and Map Number in this format and in hex: 0x(mapnumber)(bank). The command I have in here is for bank 12 map 5.**
setvar 0x405B 0x7 **X-Coordinate in Hex**
setvar 0x405C 0x4 **Y-Coordinate in Hex**
end

Don't forget to include this too in a separate level script, or it will crash.

#org @start
special 0x182
end

[psychicboy]

Originally Posted by Deokishisu

Sethealingplace, I had trouble with it too.

#org @start
sethealingplace 0x0 **Regular Pokemon Center Healing Place**
setvar 0x405A 0x50C **Map bank and Map Number in this format and in hex: 0x(mapnumber)(bank). The command I have in here is for bank 12 map 5.**
setvar 0x405B 0x7 **X-Coordinate in Hex**
setvar 0x405C 0x4 **Y-Coordinate in Hex**
end

Don't forget to include this too in a separate level script, or it will crash.

#org @start
special 0x182
end

So do I use this as a script someone walks on?

[Deokishisu]

Originally Posted by psychicboy

So do I use this as a script someone walks on?

Levelscript. If you don't know what it is or how it works either take a look at a scripting tutorial or peek into the Pokemon Center of a clean ROM, this really isn't the place for generic unrelated scripting questions.

JPAN, I'm here again with another quick suggestion/question. Would there be a way to display images larger than 64x64 using a function similar to the "show fossil picture" command you fixed up? I know there would be the actual tileset of the image and RAWs involved due to the size, but could it be done? A function such as that would serve soo many purposes. From RPG-like cutscenes, to posters, to mini-game "titlescreens" and backdrops. You could probably even use it as a cheap extra image like those found when entering Mt. Moon and Viridian Forest, or a fun way to give signposts in towns a little extra "oomph".

[JPAN]

Originally Posted by Deokishisu

JPAN, I'm here again with another quick suggestion/question. Would there be a way to display images larger than 64x64 using a function similar to the "show fossil picture" command you fixed up? I know there would be the actual tileset of the image and RAWs involved due to the size, but could it be done? A function such as that would serve soo many purposes. From RPG-like cutscenes, to posters, to mini-game "titlescreens" and backdrops. You could probably even use it as a cheap extra image like those found when entering Mt. Moon and Viridian Forest, or a fun way to give signposts in towns a little extra "oomph".

If you mean, manipulate the existing function to do it, I've tested it and no changes I made created any positive effects. I'm positive something can be done with it to create such displays, but haven't got much done in that area.
If you mean Full-display images, you can make a routine similar to the one of the map display (even simpler, as there would be no more button checking than the possible A\B button) and simply place the image on-screen. That image could be a 256 color image with a size up to the size of the GBA screen. I'm pretty sure the best way to do it would be to actually program something with the homebrew GBA lib and copy the results into a routine to be called by the script, that would replace the OW screen update. But here it's more guesswork than actual facts, as I have never even considered doing something like that prior to this post.

On a slightly related sidenote, I have finished the routines and data that would make a RTC-clock based berry system work. But after 8 hours of trying to index and insert the berry tree sprites, I came to the definite conclusion that I am incapable of putting OW sprites in a ROM through a PNG or BMP image. The mechanics are as follow:
The Plant data is composed of two variables, one that contains the total time and another that contains the actual berry data, watering times and a "watered" flag.
Two functions rule the berry tree behaviour. First is the "Update time" function. It is called at a very update-heavy routine (adding on in the keys hacked routine), and basically checks all associated variables for a plant, and if it's real, adds to its time variable. Loads it up, checks its contents to see if it's not real, if it is, adds the time, checks if the berry has expired (reverts back to seed stage) and erases the watered bit, that checks if you already watered that thing.
The other function is added to the OW hack, and checks if the OW number is 0xfeyy. If so, loads up the corresponding variable, checks for the berry tree table number, and if a berry is present, loads up the timer if it is and checks against the minimum values for that stage present in a small table (berry tree Table). At the end, displays one of those values or the seed one.
The berry tree table is a table that is composed of 24 bytes:

Berry tree data
2 bytes item number
1 byte item quantity
1 byte water quantity (not used, but balances out the address)
2 bytes seed stage end time
2 bytes OW for sprout
2 bytes sprout stage end time
2 bytes OW for small tree
2 bytes small tree end time
2 bytes OW for full grown
2 bytes full grown end time
2 bytes OW for ripe berry tree
2 bytes berry expiring time
2 bytes filler (for now)

Also, I assumed by default a time window of 1 minute, so planting a tree at minute 1:00 and the next at 1:50 would make it so both trees grow at the same time from that point forward.
The code is still in "trial mode", and it's somewhat buggy at times, but by tomorrow most bugs must be fixed. The only thing missing is some berry trees in the ROM.

So, if anyone out there wants to try, I would need as many trees as you can get working in a rom, with a total of 9 different palettes maximum. Make it over the data of any 16x32 Sprite, to make the transaction easier.

[psychicboy]

Originally Posted by Deokishisu

Levelscript. If you don't know what it is or how it works either take a look at a scripting tutorial or peek into the Pokemon Center of a clean ROM, this really isn't the place for generic unrelated scripting questions.

.

Thanks for your answer. And not to sound rude but this wasn't a completely unrelated scripted question. It was a question on how to work a certain part of JPANs engine.

[Deokishisu]

Originally Posted by JPAN

On a slightly related sidenote, I have finished the routines and data that would make a RTC-clock based berry system work. But after 8 hours of trying to index and insert the berry tree sprites, I came to the definite conclusion that I am incapable of putting OW sprites in a ROM through a PNG or BMP image.
So, if anyone out there wants to try, I would need as many trees as you can get working in a rom, with a total of 9 different palettes maximum. Make it over the data of any 16x32 Sprite, to make the transaction easier.

Maybe it's because those tree sprites are actually from D/P. I'll try some on my end tomorrow and if worse comes to worse, I'll find a GBA berry tree sprite sheet. I'm not sure what format you'd want it in though. The indexed images in a png file or a patch with them already inserted somewhere. I assume only the images would be easier on my part, seeing as I wouldn't have to worry about where to put the various frames in the ROM, all you'd have to do is import the indexed images the way you'd want them.

[>Dante<]

from which offset is advisable to begin to make script??
It is usually begun by 0x800000 but..this ROM has very more space of a normal ROM "

second thing, can seem perhaps banal, but I'm specialized in tiles and graphics...
and I have noticed that fire red contains, to inside, also animations of tiles from RSE..
the only problem is that these animations "don't exist"...
or better, they are not activated..

it's possible to activate it??