Tracing ROM address

[Orihalcon]

I'm working on a hack, and can't seem to trace the ROM source of a byte of code for the life of me.

At the beginning of the game (when we typically play as Jenna), it writes to 03002100 with a value of 05. Later, when using Felix, it holds a value of 04. Using VBA SDL-H and VBA's memory viewer, and testing using Atrius's April Fool's day hex editor, I just can't seem to find where in the actual ROM the value of 05 comes from. It's the last little bit of code I need, and it's driving me crazy! Am I crazy to ask for a bit of help?

[Daddy Poi's Oily Gorillas]

With Atrius's April Fool's day hex editor, you will only find stuff from the ROM section. (08000000 - 09FFFFFF), since that's the ROM data itself. (Both GS games stop at 08FFFFFF, though.)

Anyway, first things first? Do you know what this byte represents?

If it somehow represents the leader pc (Seeing how 04 matches with Felix, and 05 matches with Jenna), then here's what I say:

The leader value is held at 02000454.
080AE0DC = Function for making Jenna leader. (The x05 value is at 080AE0E4.)
080AE0F0 = Function for making Felix leader, and adding Felix, Jenna, and Sheba to the party. (The x04 that sets the leader to Felix is at 080AE0FA.)
(Both functions are most likely called from the map's code. Which is compressed, but decompressed to 02008000 - 0200FFFF in RAM.)
Relevant topic(s): Party member adding/removing page 2

Otherwise, I'll have to do some researching myself. :)

[Orihalcon]

I do.    That value (in a way) matches following strings (03002108, 0300210C) with an "assigned" character. 04 = Felix, 05 = Jenna, etc. I found where 2108 reads from the ROM itself, but just can't trace where 03002100 reads from. This is all relevant to changing character sprites.

[Atrius (He/Him)]

Teawater hit the nail on the head, the location you're looking for is 02000454.

To prove this pause VBA while walking into any door in the game, change the value, then unpause VBA.  You should pause the emulator by pressing ctrl + p after the transition begins, but before the screen goes completely black.  If you try to change the value at 02000454 before initiating the transition you will be unable to walk through any doors, and if you pause the emulator after the next map has already loaded this trick will not work.  If successful, when the next map loads your character, and the value at 03002100 will change to reflect the value at 02000454.


The values at 03002100 are just for sprite data, by the time this data is needed by the game the character that it should be loaded for will usually already be in RAM somewhere else.  The pointers stored in 03002108, and 0300210C point to the graphics, and animation data for the character.

[Orihalcon]

Interesting.. I have a new lead to chase after work!  Next question: would I be able to use breakpoints to find the 0x08?????? address that 02000454 reads from? Or will threplacement) through a loop as well? Lol

I got the sprite and animation pointers at 08300050 from another post (I forget which) and am good there. This is the last part I need for hacked characters (specifically Jenna's replacement) to walk and idle normally. I got it in VBA, but want to hack it in the ROM.

[Daddy Poi's Oily Gorillas]

Seeing as you say "Jenna's replacement"... It sounds like you are simply putting another character in Jenna's slot... which makes me wonder if 02000454 is really what you are looking for?

@walking and idle normally: x_x *Confused*

[Orihalcon]

No idea now, lol... but yeah, putting another character's sprites and animations in Jenna's slot. Without modding 03002100 to the right value, the character walks weird and tweaks out. I can change it in VBA, but I need to change it in the ROM.

[Daddy Poi's Oily Gorillas]

This is a bit difficult for me to understand due to my lack in sprite testing.... but to speed things up, what all specifically did you do? (A patch could help.)

What would the "right value" be?

I'm trying to figure out if the value at 03002100 really needs editing... or whether it is used to get other data that needs editing instead... Hm...

[Atrius (He/Him)]

Sounds to me like there might be something wrong with the animation data, or you're missing something else.  A detailed description of what you're doing exactly would be helpful.

The data that gets written to 03002100 comes from 08300000, except for the character index.  If you multiply the character index by 0x14 and add it to 08300000 it will give you their data's location there.

[Orihalcon]

Ok. Here's what I'm doing. I edited certain ROM values at 08300070 and 08300074 to change Jenna into Karst (08300070:8928, 08300074:4440). This writes to 03002108 and 0300210C. This part is fine (or so I think). In VBA, when I change 03002100 to the value of 0x17, Karst's sprites work just fine. If the value at 03002100 is not changed from 0x05 to 0x17, Karst does not walk correctly (her "walk right" animation is used when she walks upwards, and her idle animation when facing the right of the screen is abnormal). If I change 0x05 to 0x17, Karst walks perfectly fine, and she climbs vines and runs without tweaking out. I can change this in VBA easily, but can't find where to make a permanent change to the ROM.

[Atrius (He/Him)]

All of the data linked to the sprites, and how they're animated is going to come from that 08300000 area.  That said, even if you completely overwrite one character with another's data it still might not work properly.  NPCs just don't have all of the animations and sprites that the playable characters do, they'll end up leaking into other character's animation data and "tweak out" because of it.

Jenna's sprite data starts at 08300064, Karst's starts at 083001CC.

Here's a breakdown of what the data is:
BYTE - Sprite width
BYTE - Sprite height
SHORT - Image scale.  A value of 0x0100 is 100%, 0x0200 is 200%, and 0x0080 is 50% (In hex 0x080 is half of 0x100).
BYTE - Number of directions the sprites have (Party members have 5, NPCs have 3, battle sprites have 2, e.t.c.  Sometimes this value is different to represent that some of the directions are mirrored compared to how they usually are)
BYTE - Number of animations
BYTE - X offset
BYTE - Y offset
BYTE - Unknown
BYTE - Collision Radius
BYTE - Compression format
BYTE - Unused (Version 0.4+ of the editor uses this space to store the number of sprites)
WORD - Pointer to a collection of pointers to the graphical sprite data
WORD - Pointer to a collection of pointers to the animation data


For the most part, Karst's values will match Jenna's.  She does have a different number of directions though, hence why she bugs out when facing certain directions.

[Orihalcon]

I get what you're saying, but that one value fixes it! Karst moves around perfectly. The word "mirrored" does make sense here now that I think about it, but I know it can be done in VBA's memory viewer. It has to be somewhere in the ROM, even if not at 08300000. I'll keep at it. I'm so close I can taste it