A Pokémon that I rarely use...I'm okay with this.
You can't edit the RAM in a hex editor. Hex editors can only edit the ROM. However, I'm assuming what you meant was the offsets that point to the RAM, which you can do within the ROM. Whenever it says "point to new SEEN flags" or "point to new CAUGHT flags", you put in a pointer at that offset to the RAM offset that you're going to use. So let's say you want the SEEN flags to be stored at 0203D800, and the CAUGHT flags to be stored at 0203D860. To point to the SEEN flags, the bytes would be 00 D8 03 02. And to point to the CAUGHT flags, the bytes would be 60 D8 03 02.
You want to leave the blank ones as is.
Karatekid552 will add this to G3HS once the bugs are completely squashed. You know, if you read the comments, you would've figured this out.
There's only one bug left (with 493 anyways, I'll try to expand to 721 sometime) which is the position memory thing I mentioned in an earlier post in this thread. Though I'm thinking maybe I'll try writing a routine that will adjust the position correctly. It might seem tedious when you could achieve the same effect just by finding the error, but I can't figure out why it happens, even though I've found the routine that controls it (I posted offsets earlier).
.text
.align 2
.thumb
.thumb_func
.global positionfix
main:
push {r0-r3}
ldr r0, .FirstCheck
ldrb r0, [r0]
mov r1, #0xFF
cmp r0, r1 /*compares .FirstCheck value to FF. If not, you're outside*/
bne Outside
b Inside
Inside:
ldr r0, .Counter1Inside
ldrb r0, [r0]
ldr r1, .Counter2Inside
ldrb r1, [r1]
cmp r0, r1
bne next1
b End
next1:
mov r2, #0x0
ldr r3, .FinalPosInside
strh r2, [r3]
b End
Outside:
ldr r0, .Counter1Outside
ldrb r0, [r0]
ldr r1, .Counter2Outside
ldrb r1, [r1]
cmp r0, r1
bne next2
b End
next2:
mov r2, #0x0
ldr r3, .FinalPosOutside
strh r2, [r3]
b End
End:
pop {r0-r3}
ldr r0, .NextRoutine
str r0, [r6]
pop {r4-r7}
pop {r0}
bx r0
.align
.FirstCheck: .word 0x02000D1C
.Counter1Inside: .word 0x02000F9E
.Counter2Inside: .word 0x02000FA0
.FinalPosInside: .word 0x02000F9A
.Counter1Outside: .word 0x02000D22
.Counter2Outside: .word 0x02000D24
.FinalPosOutside: .word 0x02000D1E
.NextRoutine: .word 0x080C1D39
The reason why it's not in the Gen 3 Hacking Suit ini is because that table that PGE calls "PokemonFrontSprites" is unused by the game, as those are the single-frame Ruby/Sapphire sprites (you can confirm this by looking at Snorlax's sprite in the RS table and then Snorlax's sprite in the "PokemonAnimations" table. Snorlax actually received an entirely new front sprite in Emerald.) The table at x30A18C is the REAL front sprite table (it should have two frames per mon), and is the correct offset that both G3HS and Wichu's Tools lists as Emerald's front sprite table.Well, I went through the whole tutorial, adding in all of the 4th gen Pokémon (and Sylveon), and I have some good news and bad news. I can explain it through a picture:
I did a Word document, side by side with your tutorial, and I think there is one more offset you forgot to add in. The offset is not in the Gen 3 Hacking Suite ini, but it is in Pokémon Game Editor's, which I used to edit the names and order of all the Pokémon.
PokemonFrontSprites=&H301418