Development: The 4th gen class split in 3rd gen

[LCCoolJ95]

Hey, I found this in the thread today:

Spoiler:

FireRed (US)

0803ED54: 80 7A
0803F226: 00 29
0803F228: 00 D0
0803F38C: 02 2F
0803F38E: 00 DB
0803F394: 01 28
0803F396: 00 D0

Ruby (US) ¹

0803BA94: 80 7A
0803BFBE: 00 29
0803BFC0: 00 D0
0803C124: 02 2E
0803C126: 00 DB
0803C12C: 01 28
0803C12E: 00 D0

Emerald (US) ²

080695E8: 80 7A
08069A5A: 00 29
08069A5C: 00 D0
08069BC4: 02 2F
08069BC6: 00 DB
08069BCC: 01 28
08069BCE: 00 D0

¹ Credit to Chaos Rush for the Ruby port; I don't even have a Ruby ROM. xD
² Credit to colcolstyles for the Emerald hack; I based everything off of his post.

Seriously? All I have to do is this to get the Physical/Special Split to work in these games? Is there more to it than this, or is this really it?

 

[Uikri]

Hey, I found this in the thread today: Seriously? All I have to do is this to get the Physical/Special Split to work in these games? Is there more to it than this, or is this really it?

There is more to it than this. First, apply Doesn'tKnowHowToPlay's patch for either Fire Red or Emerald. Then, open the ROM in Pokémon Game Editor (PGE). Go to the Attack Editor internal program, and manually switch every attack's category to the proper one, since the patch changes everything to physical for some reason. You may also want to change the casing of the words so that "FLAMETHROWER" becomes "Flamethrower", and so on.

 

[Jambo51]

since the patch changes everything to physical for some reason.

This, I take issue with. It's not for some inexplicable reason, it's because the byte in question is normally set to 0, and 0 stands for Physical in the new split system. It's very simple.

 

[Uikri]

This, I take issue with. It's not for some inexplicable reason, it's because the byte in question is normally set to 0, and 0 stands for Physical in the new split system. It's very simple.

However, at the time of writing, I did not know this. Hence, instead of spouting nonsense, I made it clear that I did not know exactly why this happens.

 

[shamus24]

just want to say thanks for all the work and research that has been put in to this implementation - it's easy to apply and makes a huge difference in the level of enjoyment players (or, at least, i) have while playing hacked games.

 

[LCCoolJ95]

There is more to it than this. First, apply Doesn'tKnowHowToPlay's patch for either Fire Red or Emerald. Then, open the ROM in Pokémon Game Editor (PGE). Go to the Attack Editor internal program, and manually switch every attack's category to the proper one, since the patch changes everything to physical for some reason. You may also want to change the casing of the words so that "FLAMETHROWER" becomes "Flamethrower", and so on.

Well, that I knew about. But, that's it?

 

[Commander F]

Giga Drain is physical now? =/

 

[dd409]

Giga Drain is physical now? =/

A side effect of the patch is that all moves are treated as physical until you go through and hex-edit certain bytes (or use PGE) to reassign each individual move as physical, special, or status. The patch doesn't change each move, just the way the game handles them. See the explaination a few posts above.

I think I've found the code which causes the Mirror Coat/Counter bug in Fire Red.
Change it to this, and it should hopefully fix it.

0801F6C2: 86 [B]7A[/B]
0801F908: [B]00[/B] 2E
0801F90A: 41 [B]D1[/B]

Also, Darthatron's routine for showing the images is slightly buggy. It turns out the move index is actually DMA protected, but in a really odd way. It only gets DMA shifted after certain actions are taken within the game's overworld. Anyway - to solve this, change the parts in BOLD in Darthatron's original routine (or just copy this routine, I suppose), and then follow Darthatron's original post to insert it.

.align 2
.thumb
Start:
 push {r0-r4}
 ldr r0, .CurMoveIndex
 ldrb r1, [r0]
 lsl r1, r1, #1
 [B]ldr r0, .Move_List_Loc
 ldr r0, [r0]
 ldr r3, .number
 add r0, r0, r3
[/B] add r0, r0, r1
 ldrh r3, [r0]
 [B]cmp r3, #0x0
 beq Finish
[/B] lsl r0, r3, #1
 add r0, r0, r3
 lsl r0, r0, #2
 ldr r1, .MoveBase
 add r0, r0, r1
 ldrb r4, [r0, #10]
 lsl r0, r4, #1
 add r4, r4, r0
 lsl r4, r4, #6
 ldr r0, .SplitImages
 add r0, r4
 ldr r1, .VRAM
 mov r2, #0x30
 swi #0xB 
 ldr r0, .SplitImages
 add r0, r4
 add r0, #0x60
 ldr r1, .VRAM
 mov r2, #0x1E
 lsl r2, #0x04
 add r1, r1, r2
 mov r2, #0x30
 swi #0xB 
Finish:
 pop {r0-r4}
 ldr r4, .Some_Offset
 ldr r0, [r4]
 ldr r1, .Return_Addr
 bx r1
.align 2
.MoveBase:  .word 0x08250C04
[B].number: .word 0x00003258
[/B].CurMoveIndex: .word 0x0203B16D
[B].Move_List_Loc:  .word 0x0203B140
[/B].VRAM:   .word 0x06001800
.SplitImages: .word 0x08YYYYYY
.Some_Offset: .word 0x0203B148
.Return_Addr: .word 0x0813A17D

I'm still trying to port this bit of asm to Emerald, but I'm not having much luck finding the equivalent addresses. So far I've found that 0x08250C04 for FR should be 0x0831C898 in Emerald, but I can't seem to figure out the others. Anyone have any insight there?

 

[Tlachtli]

Change these bytes:

@0813A130: 0x2F
@0813A17B: 0x47
@0813A1A0: [Pointer to Routine, plus 1 (one).]

I'm trying to do an Emerald hack and see no one has successfully ported the sprites for Emerald yet (or at least done so and posted it here). I want to do it myself, but I have a question: what is the purpose of changing those first two bytes? I'm trying to find their Emerald equivalents, but no luck yet. I've tried putting read breaks on them in a FR rom, but never seem to trigger a read so I can't tell what they do.

Also I've been looking at the logistics of it, and I'm trying to decide where the sprite would look best. The Emerald move screen isn't as accommodating as the FR one.

EDIT: So in a huge oversight, I forgot that names could be longer than Raichu's... :/ Looks like 2 may be the better option, although I don't really like the positioning of it. That, or maybe print it over the little markings above the Poke portrait; I dunno about you guys, but I have literally never used the markings before.

 

[Deokishisu]

I'm trying to do an Emerald hack and see no one has successfully ported the sprites for Emerald yet (or at least done so and posted it here). I want to do it myself, but I have a question: what is the purpose of changing those first two bytes? I'm trying to find their Emerald equivalents, but no luck yet. I've tried putting read breaks on them in a FR rom, but never seem to trigger a read so I can't tell what they do.

I have an idea of numbers should work for BPEE, but since I haven't found the right address for the routine pointer in Emerald yet I haven't tested it:

.MoveBase:  .word 0x0831C898
.number: .word 0x00003258
.CurMoveIndex: .word 0x0201170C
.Move_List_Loc:  .word 0x0201042C
.VRAM:   .word 0x06001800  [B][1][/B]
.SplitImages: .word 0x08E3CFB0 (just where I have it stored)
.Some_Offset: .word 0x0203cf1c  [B][2][/B]
.Return_Addr: .word 0x081C3F6C  [B][2][/B]

[1] I assume this is empty VRAM used to store the sprites? It doesn't seem to be used in a clean rom.
[2] I have potential 2 addresses in mind here, but I haven't been able to test to see which works, if at all.

Also I've been looking at the logistics of it, and I'm trying to decide where the sprite would look best. The Emerald move screen isn't as accommodating as the FR one.

EDIT: So in a huge oversight, I forgot that names could be longer than Raichu's... :/ Looks like 2 may be the better option, although I don't really like the positioning of it. That, or maybe print it over the little markings above the Poke portrait; I dunno about you guys, but I have literally never used the markings before.

Honestly? I'd make a smaller icon and slap it in that gap after "POWER". That seems the most intuitive to me anyway, as, with the icon, it'll read "POWER (Physical)" "POWER (Special)" if you're looking at it. Plus, those icons are unnecessarily huge as it is. They certainly don't have to be that big on our tiny GBA screen.

EDIT: I took a minute and shrunk down the icons. I literally just took them in horizontally by six pixels and fixed up the special one so that it's centered. The icon image is set up so that it can be pasted directly over the one Darth provided, if you've already inserted it. It's attached to this post now, along with a mockup of how it would look next to POWER (with the base image shamelessly stolen from your post).

 

[Tlachtli]

Honestly? I'd make a smaller icon and slap it in that gap after "POWER". That seems the most intuitive to me anyway, as, with the icon, it'll read "POWER (Physical)" "POWER (Special)" if you're looking at it. Plus, those icons are unnecessarily huge as it is. They certainly don't have to be that big on our tiny GBA screen.

EDIT: I took a minute and shrunk down the icons. I literally just took them in horizontally by six pixels and fixed up the special one so that it's centered. The icon image is set up so that it can be pasted directly over the one Darth provided, if you've already inserted it. It's attached to this post now, along with a mockup of how it would look next to POWER (with the base image shamelessly stolen from your post).

Now I'm wondering why I didn't think of that :P The mock-up looks great.

EDIT: Never mind. I'm pretty sure most of that was wrong.

 

[Uikri]

So, I'm getting reports from people I've shared my edited Emerald ROM with that the split didn't work. Have we confirmed that after applying the patch, PGE can be used instead of a hex-editor to change the category of each move to the proper one?

 

[Tlachtli]

So, I'm getting reports from people I've shared my edited Emerald ROM with that the split didn't work. Have we confirmed that after applying the patch, PGE can be used instead of a hex-editor to change the category of each move to the proper one?

The patch seemed to work on mine. I tested it with Torchic and Scratch. I made two Roms, one where Scratch was physical and one where it was special. I set Torchic's base special attack to 255 and base attack to 1 (just to be sure that Scratch would be treated differently from the vanilla Rom). The physical Scratch did almost nothing while the special one just one-shotted May's Mudkip. I haven't tested Counter or any abilities yet.

 

[Shufflejoy]

This is probably a moot point since this is essentially a finished development now, but I was thinking... there's already a system in the 3rd Gen games to determine whether or not a move makes contact (necessary for abilities like Static)... are there any Physical moves that don't make contact? Any Special moves that do? While it offers more power to be able to have a move make contact *and* be Special, if there are no vanilla moves which are that way (or vice versa), wouldn't it be simpler to read that byte instead?

(**I didn't actually check to see if there were any moves like this, so I may have just overlooked some. I'm only really familiar with the 1/2/3rd Gen moves, anyway.)

 

[LCCoolJ95]

This is probably a moot point since this is essentially a finished development now, but I was thinking... there's already a system in the 3rd Gen games to determine whether or not a move makes contact (necessary for abilities like Static)... are there any Physical moves that don't make contact? Any Special moves that do? While it offers more power to be able to have a move make contact *and* be Special, if there are no vanilla moves which are that way (or vice versa), wouldn't it be simpler to read that byte instead?

(**I didn't actually check to see if there were any moves like this, so I may have just overlooked some. I'm only really familiar with the 1/2/3rd Gen moves, anyway.)

Within Pokemon Game Editor's Attack Editor, it has a list of checkboxes. One of them has the option of whether or not that move makes contact with the opponent.

 

[Shufflejoy]

Within Pokemon Game Editor's Attack Editor, it has a list of checkboxes. One of them has the option of whether or not that move makes contact with the opponent.

Yes, I know; what I'm saying is this.

Typically, one would expect that:

• Physical moves would always make contact
• Special moves will never make contact

If this is actually the case, it would be simpler to implement this if the routine read whether it made contact or not to determine which attack stat to use. This offers less power than the current method (in that, as it stands a move can both make contact and use the Special Attack stat), but it would be much easier to implement as the data is already in the game.

I'll look into this some more, to see if there are any moves that go against what I'm thinking. If there are any in the official games, then this is all just moot. But if all Physical moves make contact, and all Special moves do not, then I believe the best solution would be to read that byte and save people the trouble of manually setting the moves if they don't have to.

 

[DoesntKnowHowToPlay]

rock throw, rock slide, earthquake, razor leaf, etc. are all physical but don't make contact

if you go into the future there's also grass knot which is special but does make contact

 

[Shufflejoy]

rock throw, rock slide, earthquake, razor leaf, etc. are all physical but don't make contact

if you go into the future there's also grass knot which is special but does make contact

Understood. Now that I know for sure, I suppose I'll just go ahead and edit the moves manually. Thanks!

 

[Teh Blazer]

Can I apply DOesntKnowHowToPlay's patch to an edited ROM or can it only be applied to a vanilla FR ROM?

 

[Shufflejoy]

Can I apply DOesntKnowHowToPlay's patch to an edited ROM or can it only be applied to a vanilla FR ROM?

As long as you haven't patched the routines for calculating the attack stat to use in battle, I believe you should be fine (though you will have to manually set each move to either Phys/Spec in PGE, a hex editor, or using Nightmare).

Of course, the simplest way to answer your question is to just say: Probably. Back up your ROM first, though.