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

Minun's also the only pokemon with the "Minus" ability. Is it possible that this has something to do with it or is it more likely due to Minun's species? If someone were to keep tooling around Minun's various traits and pointers, they might find something. I would, but I prefer to hack Emerald. So at the moment, I'm just a brainstormer in this matter.

And I'm aware that the ability being related is a strange guess, but it's also a strange glitch. Something about Minun has to be affecting the attack type, as it's incredibly strange that Plusle is unaffected. My theory is that it could be a programming error related to the ability and special/physical attack of Minun (the glitch was probably small enough that Nintendo's developers either missed it or ignored it).

EDIT. And perhaps the game's routine for checking the special attack modifier from "Minus" is different than the routine for "Plus" somehow? I'm just throwing things out there so don't overreact if I'm way off base with this one.

I've searched and found all the places in Ruby code that match the places where Firered is edited by this patch. I applied the same edits hoping to port it, but that failed(go figure). I'm not sure if that's because the ram addresses are different or it uses a couple of different registers in certain spots (r6 for r7, r1 for r2, etc). Anyways, if anyone wants to try or is interested here are the addresses:

https://codepad.org/UmwoSKKN

Ive applied this, and the ability Flash Fire now causes the game to crash when the poke uses a fire move next (the opponent) or perhaps any move.

This, with the Minun bug makes me think something isn't quite flawless here. I'm just saying..

I played around with this a bit too, and it seems to me that the Minun glitch is definitely caused by the ability Minus. I changed its ability around using YAPE and when I switched it to something other than Minus it worked fine. Except for Flash Fire, as mentioned above; that seems to crash the game if you use a fire-type attack after receiving damage from a fire-type attack, but not before.

This patch should probably be tested with all abilities that react to damage. I'll certainly be doing some of that, since I plan to use this patch for the hack I'm working on (first-time hacker - and poster - here!).

I played around with this a bit too, and it seems to me that the Minun glitch is definitely caused by the ability Minus. I changed its ability around using YAPE and when I switched it to something other than Minus it worked fine. Except for Flash Fire, as mentioned above; that seems to crash the game if you use a fire-type attack after receiving damage from a fire-type attack, but not before.

This patch should probably be tested with all abilities that react to damage. I'll certainly be doing some of that, since I plan to use this patch for the hack I'm working on (first-time hacker - and poster - here!).

Edit: I did a bit of testing with some abilities that I thought might be relevant. Volt Absorb, Water Absorb, Plus, Huge Power, Hustle, and Pure Power all do not crash the game, although with Pure Power I couldn't really tell whether or not the effect actually worked.

That, and the blaringly obvious error that grass- and fire-type STAB moves (or it could be certain Pokemon using STAB, I haven't ascertained yet) cause the game to crash in no$, which I prefer because it can emulate at about twice the speed of VBA.

Around the time you came out with this, I was already working with it in the same way (comparing the Japanese Touhoumon Renkou version and an unpatched Japanese rom), so I may try that again (or take a closer look at what you've taken note of). If I find anything, I will post it here, but you've done pretty much as much as I expected to be able to (get a buggy version working).

To document what I've tested in no$gba:
-Using a fire-type move with charmander causes a crash. Normal has no such effect
-Using grass-type move with Bulbasaur crashes; Normal and fire have no effect
-Using water-type move with Lapras and psychic-type move with Hypno has no effect

So obviously there are some types I haven't checked, and it's possible that it's just Pokemon up to a certain point in the dex.

The "STAB move"-error does not occur in VBA (though you might already know this) and I tested whether Confusion was regarded physical or not by editing with YAPE (too lazy to check hex) and Squirtle almost OHKOd Bulbasaur with Confusion, with ~5 Attack and ~30 Sp. Atk, therefore I would think Confusion is indeed Special.

I only applied the patch posted by Ivee, so perhaps you applying both patches messed something up.

The freeze with Minun does occur however, but I can deal with that since Minun is kinda redundant... I am not experienced by any means, but I will check some stuff in Hex and see if I can find any obvious things that cause this.

edit:

Further tests: Pure Power seems to not have an effect at all.

Has anybody run into (or had the chance to) on the Touhoumon roms? Such as Pure Power, Flash Fire and Minus not working or causing issues. I know the STAB thing isn't a problem on any emulator with Renko version (which is the rom I was using), but it is possible that the other problems were solved by simply not using those abilities, since everything in Touhoumon is fakemon (sort of). I suppose I'll be looking into that tonight.

As for actually looking at the code involved in this, I haven't had much more chance to look at it, as I've been struggling to fix a variety of problems that cropped up in one of my hacks after an hardware failure (such as everything past about offset E-something, including basically a bunch of FF freespace and about a thousand bytes of actual game mechanics, being overwritten by 00's), which is taking all my time.

Oh wow, I derped up hard in my previous comment.

If the Japanese hackers figured out how to implement this so far in advance of us, I doubt they'd put up with just working around really dumb problems like what we're having. Probably we just need to find the code where the info for those abilities is accessed in our game and in those games, and perhaps the information for STAB bonus as well, see that, oh, wow, it's different from the original code, and change it ourselves. I doubt it'll take more than a bit of trial-and-error from there to get a fully working patch.

With that said, I guess we should kind of try to figure out what has actually been done here, in ASM. Just maybe later. To paraphrase Bacon, science should be done in pursuit of practicality.

Gamer2020 said:

Can someone put up the Japanese patch? I don't feel like doing the changes to BPRJ manually just to look into this.

Click to expand...

Hang on, I'll make a patch and edit my post.

EDIT:
Sorry, I'm still getting the hang of using Linux again.
https://www.mediafire.com/?q4zhxnh2gndua2s
I did the patch on BPRE 1.0 so that anybody else interested doesn't need to find BPRJ.

I found the ROMs of Touhoumon Emerald on my PC, normal & DPSS versions. So, I made a pair of IPS patches from them. Feel free to use it to improve the DPSS FR patch, AND make an Emerald version too:

https://www.mediafire.com/?z4ckut6o2yi6gcx

Remember it to use it on a Japanese Emerald ROM. Sorry if I can't help more, but good luck for you all on the hacking works!

Hello, I'm (marginally) back for the time being. I see my "perfect" patch wasn't perfect after all but this within itself is a misdemeanor because nothing programmers ever come out with is truly perfect, EVERYTHING will always have bugs, even the more professional of applications.

But enough about that, let's work on the responses.

Putin said:

Around the time you came out with this, I was already working with it in the same way (comparing the Japanese Touhoumon Renkou version and an unpatched Japanese rom), so I may try that again (or take a closer look at what you've taken note of). If I find anything, I will post it here, but you've done pretty much as much as I expected to be able to (get a buggy version working).

Click to expand...

This is exactly what I did so I think the most I did for you was save you about 5-ish hours of work and thorough testing. From what I've seen and played, the Japanese revision of the code that adds the system is indeed well put together, as none of the bugs posted in this thread are apparent in the Japanese ROM, which leads me to believe that more then just the registry values and memory positions are different between the hard coded mechanics of the US and the JP ROMs.

The "Minus" bug truly baffles me; I can't think of a reason why it would do this. If the Plus ability isn't bugged but Minus is, then my patch might have altered the position of Minus' code, which is causing the game to crash because the pointer to Minus' code is now incorrect. I'm not sure how this could actually be possible though, so don't quote me on this. It still confuses me.

Flash Fire, however, I can explain. Flash Fire's code references the edited part of the mechanics as part of bypassing the damage. Flash Fire is meant to make the Pokemon immune to Fire moves, so in order to do this, it references the damage dealing code; which this patch edits. Fixing Flash Fire means changing the address that Flash Fire's code references so that it can properly bypass defense. It's relatively easy to do so long as you know where Flash Fire's code is; I don't know it personally however. Once you know, it's just a matter of comparing an unpatched ROM to the patched one and finding the values that Flash Fire's code references.

no$gba has far from perfect emulation. From what I remember, the version of touhoumon that I grabbed this code from doesn't work in no$gba either. Suffice it to say, you sacrifice some compatibility in using this patch. If you had the debugger version of no$gba though, with some ASM knowledge, it's quite possible to make a patch that is compatible with it.

The Japanese continue to impress me. I was never aware there were DPSS versions of Touhoumon Emerald. Unless Putin wants to give a whack at it this time, I could very well cross compare both those patches and make a DPSS patch for Emerald. It'll likely contain the same bugs, or possibly new ones, however, which is a job for a good ASM hacker. I'm merely here for the boring jobs no one else wants to do. ;o

Hey, good to see you back. I didn't work on this like I said I would because some pretty serious real-life stuff came up (and is still up), but I will get to it when I get to it, if someone doesn't get there first.

Man. I tried cross comparing the (U) and (J) versions of the Emerald ROM only to find out that neither of them are really similar. I even looked in the VBA debugger, the same exact spots in the mechanics both use entirely different coding. Changes in code between the (J) and (U) versions of Emerald are not interchangable because of this so getting DPSS into Emerald is probably going to take a lot of additional work, unless I'm missing something.

Correct me if I'm wrong, but I could only find one relevant check in the entire ROM for the class of the attack (as there was no class split outside of battles at all).

I'm struggling to understand the relevance of all the code you hacked in, since the only thing we're changing is how the game determines what attack falls into which class. Regardless of how a move actually works, all we want to change here is the type-based class system into a byte in the move's data based system. Is this correct?

If so, the mechanics for special. atk/def and atk/def already exist within the game. There doesn't seem to be any need whatsoever to hack those mechanics. All we need to do is change the one check, so that it reads the byte in a different way. As an ASM hacker, I can assure you from experience that the rest of the changes are pretty much irrelevant.

I have no idea if ANYTHING you said is true or not. All I know is that if I change the hexidecimal bytes in the (U) ROM of Fire Red to match those of the (J) ROM at the appropriate places then it works. I don't know why it works; I just know it works because I tested it before. I never actually experimented with any other changes because I'm no ASM hacker.

If you believe in such things, then why not demonstrate it? Pitch in, help us, this isn't one person trying to do something for their own personal gains, I want this to be a community effort that all of the community in whole can benefit from. I've said this multiple, multiple times, but the perfection of the patch can only be achieved with an experienced ASM hacker and I am not one of them, so any help is greatly appreciated not just by me, but anyone who uses this patch to make their hack better.

JJames19119 said:

I have no idea if ANYTHING you said is true or not. All I know is that if I change the hexidecimal bytes in the (U) ROM of Fire Red to match those of the (J) ROM at the appropriate places then it works. I don't know why it works; I just know it works because I tested it before. I never actually experimented with any other changes because I'm no ASM hacker.

If you believe in such things, then why not demonstrate it? Pitch in, help us, this isn't one person trying to do something for their own personal gains, I want this to be a community effort that all of the community in whole can benefit from. I've said this multiple, multiple times, but the perfection of the patch can only be achieved with an experienced ASM hacker and I am not one of them, so any help is greatly appreciated not just by me, but anyone who uses this patch to make their hack better.

Click to expand...

Please don't think I was trying to suggest you were having a go at me, because I wasn't. I was genuinely impressed with the effort you put into the patch, even if you didn't truly understand why you were changing stuff.

As far as I can tell, however, most of the patch is entirely unnecessary.
I was actually asking for people to back up my theory, as if I was right, then it only takes a simple small routine, rather than a large patch.

The Physical/Special split has existed since Generation 1, has it not? (It wasn't based on an attack by attack basis of course, but used the type to determine it). My theory is that the code needed for the actual mechanics of it has always existed in the ROM, but that the split was done "wrong", so I simply modified that one check rather than all of the mechanics.

I haven't released it yet because I'm still testing it along with the rest of the 649 Patch (Moves, abilities and everything else too). Once I'm sure it's bug free, I'll release it, but not before.

It's okay, don't mind me, I'm just an avid follower of the prospect that people back up their claims, though if you're not sure yourself then that's understandable.

If you're working on a patch yourself that does this already then it'll likely be ten times more effective then my patch as it'll be developer brewn by someone in this community (and more importantly, someone who speaks english) and won't rely on wild mass guessing. I'm sure I've made this disclaimer too many times to count already but the patch I've made is based entirely off of assumed hex code that I only know works because I've personally tested it. I really don't have any idea how it actually works because I'm horribly unskilled in ASM; obviously a patch made by someone competent at ASM will work infinitely better then a patch made by someone who's working off of pure trial and error, so I will be exceedingly thankful myself, if everyone else wouldn't be, for your patch, so lots of good luck to you on that.

tl;dr: I will stop acting like a dork now. :V

Is it now possible to implement the class split into Emerald?
Where can I find the offsets of all the moves in Emerald?

I made an account just so that I could bump this topic.

I desperately want the physical/special split in english rom hacks, with all my heart. I have little experience, but I think I can see what Jambo was getting at.

In the code, there must be something like this:

Pokemon_attacks{
If(move.type = fire){
use_special_atk()
}
if(move.type = fighting){
use_physical_atk()
}
etc
etc
}

and what we want to do is make it so that it goes like this:

Pokemon_attacks{
If(move.split = special){
use_special_atk()
}
if(move.split = physical){
use_physical_atk()
}
}

First we have to find where in the code this actually happens. after that, we'd need to find a way to assign the binary variable "split" to a move. I propose we could use the "makes contact" variable. Sure, moves like earthquake would make contact suddenly, but that's a small price to pay for the glory of a physical/special split.

It would look something like this:

Pokemon_attacks{
If(move.contact = no){
use_special_atk()
}
if(move.contact = yes){
use_physical_atk()
}
}


I realize that the actual code probably looks more like the matrix than javascript, but something analogous to what I suggest ought to exist somewhere in that mess. I'd help if I could, but I have no idea where to start.

PLEASE, people who know their way around code, MAKE THIS A REALITY.

First of all, ASM is not that simple. Variables don't just come and go like that, if there's not enough room for a value in the registers, then you've got a problem.

More over, there's no need to use the contact byte in the attack data because there's enough space in the data struct to allow three more values that can reach 255, which is more then what we need since all we really need is just a boolean. The contact byte can stay the same so long as the code can be altered to take advantage of the new flag in the struct, which is what my patch for Fire Red does, albiet in a highly messy and unoptimized way. But what this means is that it's most certainly possible.