Class System Hacking Topic

[Daddy Poi's Oily Gorillas]

Why don't we list the unique values? Also, this is grabbed as a short (16-bit) in the assembly data, right? Okay, good...

Well, I spot 9 different values they use... if it helps at all. (bottom-left unknown in class editor.)

BASE-TEN 0 24 2312 3340 15391 17177 17696 19220 21783

HEXADECIMAL 0 18 908 D0C 3C1F 4319 4520 4B14 5517

EDIT: And I just saw the first page, well, I'm planning on checking the assembly section later on, (Hopefully, if I have the patience to open the SDL-H version and get to a ---...) I mean, so I can post what happens here, if it is a bit long, I'll probably have to forget about it. Edit Again: I can't find a breakpoint, so I'm not sure how this'll go.

Recording this for self-reference= Squire=080C1698; Flame User=080C57E4


Edit Once More- Can anyone test it with the password, although, I doubt this would effect anything, but...
I would like to check items with Elemental Power and Resistance as well....

[Kide]

OK, I think this is the best thread to post what I found out. I don't think this qualifies as necroposting since there is not a single post with this information, so here it goes.

Apparently the game tries to read every class within the correct Type one by one. If the min elemental level requirement for a class checks, a character would get said class. So, if you look at the Class Editor, classes with a higher index number would get preference over ones with a lower number. What I mean is, classes closer to the bottom of the list get preference over ones closer to the top of the list. Let's look at two examples.


Example 1

Erase the data from the Swordsman (Venus) class at slot 40 and put it anywhere between Protector (slot 44) and Dragoon (slot 60). Now Swordsman is the only availabe class within its line. It doesn't matter if you set 1 Mercury Djinni or 7 Mercury and 2 Venus Djinn, Isaac and Felix can only be Swordsmen, as it will be checked after the other classes and its min elemental level requirement will be always met. However, they do have access to the Dragoon line.

This time, move the Swordsman class to after the Paladin class (slot 62). Now Swordsman is the only Type 3 class available to Isaac and Felix, as it will be the last class checked within all type 3 classes and its min elemental level requirement will be always met. They will never be a Dragoon, Templar or Paladin in this case.

NOTE: Technically there's no need to erase the data at slot 40, this was just to make sure there are no conflicts between classes with the exact same requirement.


Example 2

Let's say I wanna create a tri-elemental, 3-tier class line for a Mercury Adept, but using Venus and Mars Djinn. Mercury Adepts originally have their Venus level higher than their Mars level, so the class type to be used would be 8. The level requirement for each tier would be

Tier 1 - 3   5   3   0
Tier 2 - 4   5   4   0
Tier 3 - 5   5   4   0

Now I look into all type 8 classes to see where a conflict would appear. The trouble here lies with the Seer (Mercury) class line (slots 100-104). So I would have to put my new classes anywhere after slot 104.


Ok then, here are the two main rules applied when creating and sorting classes:

1) Tri-elemental classes should have a priority over dual classes, so they'll ALWAYS have to be placed AFTER these.

NOTE: Technically this would apply similarly between dual and mono-elemental classes. However, since mono classes have exclusive class types, they should never conflict with other classes (unless you do some crazy stuff, maybe), meaning they can be placed anywhere, really.

2) Classes with higher elemental level needs should have a priority over ones with lower needs, so they'll ALWAYS have to be placed AFTER these.

Knowing this, it is possible to create ANY kind of class (there are probably some limitations to this, though), as long as classes are sorted properly. For example, you could create four-elemental classes that do not need an item to be equipped. They would work a little differently when compared to item classes, unless you manage to work it out by creating some additional, "copied" classes. Take a look at the example below:


Example 3

Equip the Tomegathericon on Piers. Now set 2 Djinn of every other type to him, making him a Necrolyte. If you set a 7th Djinni, of any element, Piers will still be a Necrolyte. So if you want your four-elemental class to work this way...

Firstly, as told in Example 2, a Mercury Adept's original secondary element is Earth. So, again, the class type I'll be using is 8. The class set would look something like this

Tier 1 - 1   5   1   1
Tier 2 - 2   5   2   2
Tier 3 - 3   5   3   3

(Yes, only a 3-tier line, opposed to item classes being 4-tier)

Do not forget though, since these are four-elemental classes they should be placed after all type 8 tri-elementals (at least Tier 3, as Tiers 1 and 2 don't conflict with tris, but they do conflict with duals).

OK, let's test it. Set one of each non-Mercury Djinn on Piers and he'll be Tier 1. Now, if you set a Mars/Jupiter Djinni to him, his class will change to Wanderer/Elder. To prevent that, you create two additional "Tier 1" classes (note that they will be the exact same classes), but this time you use class types 9 and 10. You would have to repeat this process regarding Tier 2 - Tier 3 transition as well, so in the end, the set would look like this

Tier 1 - 1   5   1   1  Class Type: 8
Tier 2 - 2   5   2   2  Class Type: 8
Tier 3 - 3   5   3   3  Class Type: 8
Tier 1 - 1   5   1   1  Class Type: 9
Tier 2 - 2   5   2   2  Class Type: 9
Tier 1 - 1   5   1   1  Class Type: 10
Tier 2 - 2   5   2   2  Class Type: 10

So this 3-tier class line would in fact take 7 slots to work as an actual four-elemental class.


***IMPORTANT***
All these examples consider you keep the original party members' elemental levels intact. If you somehow change those you'll have to think an appropriate way to deal mainly with the class type, as it could be changing within a class line and you might not realize that.
As Atrius pointed out below, "characters actually do have .3, .2, and .1 in the elements that aren't their primary, not 0"

Well, I think this is it. I recommend anyone with some free time to try this out, and try some other stuff too. If you notice any errors on what's been said here, then please report.

[Aile~♥]

You, sir, are awesome. I think Role should take a look at this. And Atrius, too, for that matter.

[Misery]

Well, it seems logical considering classes with higher requirements are placed further down in their respective groups... I honestly hadn't thought about it though, I tend to miss picking up important details like this. But now that you bring it up, I'm surprised no one else thought about it either, it seems like a likely cause for class problems that people have had in the past.

Now, I know a lot of stuff is stored backwards since the system reads less significant bits first and whatnot, but I have never encountered data items which themself are stored in reversed order within the ROM. Then again, there's a lot going on inside the GBA that I don't know of...

Knowing this, it is possible to create ANY kind of class (there are probably some limitations to this, though), as long as classes are sorted properly. For example, you could create four-elemental classes that do not need an item to be equipped. They would work a little differently when compared to item classes, unless you manage to work it out by creating some additional, "copied" classes.

I also think it should be, as long as you make sure the requirements put the classes in the right element group.

[Atrius (He/Him)]

Very nice, good work Kide.  Strange that the game doesn't keep track of the Elemental requirement count of the current best match while assigning classes to make sure it doesn't give you one that requires less.

The class system is certainly one of the more confusing aspects of the game, I'll probably need to add some tools like something to check if you got the sorting right in the Editor.

You actually brought up another good point too, the characters actually do have .3, .2, and .1 in the elements that aren't their primary, not 0.  I don't remember seeing it affect anything when I was looking at how the class type value worked, but I guess I'll have to take a closer look it.

[Kide]

I'm surprised no one else thought about it either

Yeah, me too. I know people tried to test these things extensively. Maybe if I was a bit smarter I could have figured it out earlier, as there were many times I could have noted it and they were simply overlooked.

it seems like a likely cause for class problems that people have had in the past.

Yep. Definitely true. When I think about it now, every failed attempt I made when creating new classes can be explained now. Every single one.

You actually brought up another good point too, the characters actually do have .3, .2, and .1 in the elements that aren't their primary, not 0.

To tell the truth, I thought this was... how should I say it... well known to most people here, but people were overlooking it in a sense. Although, when you think about it, that would prevent any character to achieve base classes, as there would always be a secondary element. I guess the game just checks if the level is greater than 1 when attributing class types.

Also, I'd appreciate if anyone who tried to recreate those examples could confirm they worked exactly as said, if this is not asking much.

[Aile~♥]

Actually, fact is there was a table to determine which class values work for which, it's somewhere earlier in this topic I believe. But now the question is: Which theory is correct: Yours, or Atrius's?

	|	|	|	|
	1|	8|	4|	8|
	3|	6|	3|	10|
	4|	9|	2|	9|
	5|	10|	5|	7|

Select the column that represent's the character's primary element, and the row that represent their secondary element.  So if a Mars adept was given a Mercury Djinni their value would be 3.  An adept that has no true secondary element is treated as though their secondary is the same as their primary.  There are a couple oddities as to which combinations are regarded the same, I double checked my work, and I assure you that they're not mistakes on my part.

If two or more elements are tied for primary one of them will become primary, and one will become secondary.  If two or more are tied for secondary only one will become secondary, and the other(s) will not affect the class type value at all.  Merely due to the way the algorithm performs it calculations the elements end up being prioritized as such: Jupiter > Mars > Mercury > Venus.  Basically Jupiter always wins in a tie, and Venus always loses.

[leaf]

They're both right. I think the best way to look at it is atrius explaining the art ("this works"), and kide explaining the science ("this is how it works").

[Rolina]

There's a problem with this - class order really doesn't mean much - it's class position.  Basically, the data value.  In my class template, they're all in the same order, however, neither team can access the Tri-Element classes outside of the Tri-Hybrid classes.  I've mentioned this several times, trying to get Atrius' attention to see if he'd check out why in the code, but to no avail, as I have yet to get a reply from him.

I think it's less to do with the order they're put in, and more to do with where they have been put.  If you'll notice, at every 10, a new class line begins.  My suggestion is that the patch be tweaked so that this is less of an issue - basically, so that it doesn't check for where exactly in the code it is.  This would allow for things like sorting, and adding new item classes

[Kide]

Did you try running those examples? Did they not work? Please tell me your results on this if you've got free time.

[Rolina]

Have you seen my template?  It follows everything in order.   It's not the order that matters - it's the actual position.  What I'm hoping we can do with the patch is to make it so that the position is no longer an issue.

[Kide]

***IMPORTANT***
All these examples consider you keep the original party members' elemental levels intact. If you somehow change those you'll have to think an appropriate way to deal mainly with the class type, as it could be changing within a class line and you might not realize that.
As Atrius pointed out below, "characters actually do have .3, .2, and .1 in the elements that aren't their primary, not 0"

Maybe in red it's more noticeable.

By the way, your template was very helpful for me when doing some testings, so I thank you for making it in the first place.

[Rolina]

Yes, I did notice that.  It changes nothing about what I said.

[Kide]

Actually, it changes a lot. From your template's thread

All of my templates utilize updates from Dark Dawn, such as Blast (nova) → Starburst, and have tweaked base element levels so that elemental 'weaknesses' in base classes make sense.  Basically:

Element → 54
Symbiote → 3
Neutral → 2
Opposed → 1 (weakness)

Ok, let's try this. Using your template, set 3 Mercury and 3 Mars Djinn to Isaac, to try to make him a "Roc Fla Mer 1", a type 3 class. However, he'll get the "Roc Fla Sym 2" class, which is a type 4 class. This means his primary element is Venus and secondary is Mars, and not Mercury. This happens because his current elemental levels are 5.4  3.2  3.3  0.1

For Isacc to be able to achieve the "Roc Fla Mer 1" class with 3 Mercury and 3 Mars Djinn, you would have to set the class type to 4. But doing just that is not enough. As the "Roc Fla Sym" line comes AFTER "Roc Fla Mer" line, and both will be using class type 4 now, and those elemental levels would allow Isaac to be a "Roc Fla Sym 2" (the LAST class on the list which the requirement checks), this is the class he would get.

Now, if you place the "Roc Fla Mer" line (a tri-elemental line) anywhere AFTER the "Roc Fla Sym" line (dual-elemental), things would work alright.

[Rolina]

Element levels were optional, and those values don't affect element levels themselves, but rather resistances, so it makes more sense.  There's always the option to change them back.  That should be very little influence on it.

As for what you're saying, I'll test it out.  If it works, I'll upload a new template, but if it doesn't...  Well, I'd not be surprised.  The order I use is exactly the same as in the games, so it shouldn't be something like that.  Also, Roc Fla Mer is value 3, not value 4.  I'll assume you mean to change the value to 4 instead...


Edit:  

Hey, would you look at that!  It doesn't work.  How I tested this:

I edited the first team to follow your specifications.  I kept the second team as is.  I then gave both Isaac and Felix Dragoon class, put the remaining 3 djinn on standby, and traded standby djinn to show the result.  With Isaac affected by the changes... he's exactly the same.  I even set everything to 4 for Tri-element classes, and put them after symbiotic classes like you suggested.



See?

Now, this means one of two things - either I misunderstood you, in which case I'll need you to make an example and show me, or... well, it's wrong.  Either way, it requires you or someone else to duplicate the results so you know I'm not bullshitting you.  While a fix like that would be awesome, sadly it's just not as simple as that.

Please see my next post - the guy was onto something, I just didn't quite understand it yet.

[Kide]

Also, Roc Fla Mer is value 3, not value 4.  I'll assume you mean to change the value to 4 instead...

Well,

to try to make him a "Roc Fla Mer 1", a type 3 class.

you would have to set the class type to 4.

I think that's exactly what I said.

Also, the first test I would do if I were you would be reset the elemental levels back to their original values, as in

Element → 54
Symbiote → 1
Neutral → 3
Opposed → 2

By doing only this, your template will work PERFECTLY, as I already tested it.

[Rolina]

I've also changed that back now.  Instead of getting RFS2, I'm getting Roc Mer 2, which still isn't what I should be getting.  Can you do a complete restructure of my template to show me what you're talking about?  Only change Team 1's setup, so I can see the difference between them.  I'd be really thankful if you could do this, so that I can more clearly understand what it is you're asking me to do.

My template works the second you fix the element values back.  So those do matter... That's good to know.  So basically, what you were saying was that those actually cause the order it checks things to be changed, am I understanding this correctly?  That to use those values, I'd have to reorder them in the same way I reordered the element values?

[Kide]

There's one thing I've been keeping to myself, 'cause it might not be THAT important after all, but there's no harm in saying it I guess.

Regarding those elemental level ties, I think it's now clear to everyone that if you keep Party Members levels intact, as in 54 3 2 1, a tie will never occur. But if you were to change those to something like 54 4 4 4, or 50 50 50 50, ties would certainly be possible. And from what I tested, the actual tie-breaking criterion is Venus > Mercury > Mars > Jupiter, so it's the reverse of what Atrius said it was (which I find really weird).

Of course, if you're not planning on changing ELs in such a way, this information is useless, but some people might do it, so there it is.

[Atrius (He/Him)]

I must have misread something in the code, my mistake...

[Daddy Poi's Oily Gorillas]

Hmm... I think it's time for a cookie. Okay, unknown at the bottom of the Class Editor are three bytes. Each indicating Ability Effects. (Too bad you can only use 8 - 85, though.) EDIT: Not all of them, though.

So if you are trying to get a breakpoint, than use an ability that has an effect between 8 - 85. Enfeeble, for example.

020309F1 must not be 00. (Or else it will look at the 080B9E7C database for the three ability effects instead.. Which looks like the Enemy Database... The three unknowns in the Enemy Editor! Wow, that's like hitting two birds with one stone.

I'm guessing when 020309F1 is not 00, then it is used to pick a class.

Function: 080B06E8 (Called from 08080A2E.)


I will be seeing how ability effects of classes affect the game soon... but all this is evident by looking at the code.



Edit: It seems like you get a 25% greater success rate... Ability effects that already have 100% don't need to look at this data... And the base percents are all done by a certain function, this function uses negatives as a way to also skip this bonus check... and there also seems to be a number (r9) that says how many times to generate a number and compare... (67, 80, and 85 (non-hex) have it set to three times, the rest are just 1 time.)

Number 85 is May inflict Stun, it seems to be the second one, but it's nice to know it is slightly different than the first. Knowing the success rate it has...

To edit the base success rates, one could rewrite that function and create a database with those values... using 0x00-0x64 and 0x80-0xE4