Golden Sun Hacking Community

Okay, by far, the greatest problem we've come across in hacking this game seems to be the chaos that the class system turned out to be.  When experimenting with the class editor, please report your findings here.  This way, once we gather as much info as we can, we might be able to make heads or tales of this, and either Atrius will be kind enough to toss out the old one and program a much more user-friendly version via a patch (not likely), or we can find out how to actually manipulate the darned thing (also not likely, but more likely than the first option).

So, here's what I've been testing...

As you all know, I HATE Felix and Sheba, and have been struggling to make them not clones.  So, what did I do?  Previous testing suggested that the top value was a character value or something... Isaac and Felix seemed to be assigned value 1 for their base class, Garet value 2, Ivan and Sheba value 7, and so on...

I figured, all I had to do was swap Felix and Sheba's element levels (turning Felix into a Jupiter Adept and Sheba into a Venus adept) and make mockup base classes for them.  After a bit of work, I tested it...

Felix and Sheba's CLASSES swapped.  Apparently, it's not character values at all.  Now Felix was suffering from Piers Syndrome, only worse, because his base class was a mage now.  And Sheba was promoted to having Jenna Syndrome, being a mage-like character with a bunch of fighter classes.  Totally didn't work.  So I figured:  What happens if I swap Jenna and Sheba's values instead?

Jenna got Ivan's class.  Sheba got GARET'S class.  Interesting.  So I swapped Jenna and Piers this time, thinking that since I'm swapping the two who have unique classes in GS2, they'd get each other's.  Jenna got MIA'S class.  Piers got GARET's class.

Apparently, there's something in the code that is VERY SPECIFIC about how Jenna and Piers have their own unique base classes.  It has nothing to do with character number it seems...  Even by swapping the top value for their original base classes, they were stuck with the GS1 classes.  Apparently, value 13 in the top values refers to ONLY Jenna, and ONLY when she's got nothing but Mars Djinn equipped (likewise with Piers, his classes and mercury djinn, and the value 14).

Edit:  Pinned until we figure this out.  When testing with the editor, make this one of your top priorities, doods.

Only thing we really have to do now is figure out what the bottom 2 numbers mean (underneath the levels & abilities) and how to separate Felix's and Isaac's class and Sheba's and Ivan's class. Only thing I remember about the bottom 2 numbers is that several classes share the same bottom 2 numbers. Here's a chart showing who shares what:

0 0
---
Water Seer Class Series
Swordsman Class Series (Both)
White and Pure Mage Class
Mariner Class Series
Pierrot Class Series

24 0
----
Seer Class Series (Both)

2312 0
-------
Brute Class Series
Samurai Class Series

3340 0
-------
Guard Class Series
Tamer Class Series

15391 0
--------
Squire Class Series

17177 0
--------
Apprentice/Page Class Series
Ninja Class Series
Flame User Class Series

17696 0
--------
Wind Seer Class Series
Dragoon Class Series
Hermit Class Series

19220 0
--------
Pilgrim Class Series
Ranger Class Series

21783 0
--------
Medium Class Series
Dark Mage Class Series

Only thing we really need to do is piece together the clues to discover an ever better objective

One of these days I'll scan through the code and figure out what the unknown values are all about.

Quote... This way, once we gather as much info as we can, we might be able to make heads or tales of this, and either Atrius will be kind enough to toss out the old one and program a much more user-friendly version via a patch (not likely) ...

Not likely?  I wouldn't say the old one needs tossed out completely, but if there's something that can be done to improve it I'm more than willing to.

That idea basically said that you'd remove the old system, replace it with a new, similarly functioning one from scratch, and do all that debugging that goes along with it.  That is a LOT of effort.  Thus, Not Likely.

The only thing I can suggest is that class values determine who can use the class. I tried changing Pilgrim (wind) around, switching the values to see if I could get it to be available in all stages to both Sheba AND Jenna. Didn't work. I kept getting NPC class.

Well Jamie, if you were talking about Role, then here's her post (quoted) from a former similar topic with her findings.

Quote from: Role on 22, May, 2009, 05:32:00 AM
Greetings, fellow testers!  As we all know, there's quite a bit of stuff that we don't know what the hell it is.  This is the thread you will use to post your findings as you fiddle with stuff to find out what it is!

Now then, for the purposes of this thread, if something referrers to something character specific (such as in the class editor), don't refer to them by name, but rather by the character number (as seen in the character editor).

Alright, I'll start off with some of my findings in the class editor.


Class editor, top value.
1 = Character 0 and Character 4's base class.
2 = Character 1's base class
6 = Character 3's base class
7 = Character 2 and Character 6's base class.
12 = NPC class
13 = Character 5's base class
14 = Character 7's base class
15 = If Mysterious Card is equipped
16 = If Tamer Whip is equipped
17 = If Necronomicon is equipped.

After swapping values 13 and 9 between the Fire Monk series and Flame User, Character 5's base class was now the Fire Monk series, and after setting 5 fire djinn (I forgot to change the element level requirements for the Flame User series), character 3's class changed to Flame User.

I can tell these are linked to the characters, so what we need to do is figure out the specifics.  There must be a place in the code that says which class values a character can use.  If we could solve this and figure out how exactly it works, we could have 0.3 have a class selection thing in the character editor.  In otherwords, we could have a way to tell which classes a character can use.  VERY useful for making certain characters NOT SUCK due to having crap for class selection, and for taking out duplicate classes.  Not to mention the sheer potential it brings for custom classes.

Link to the previous topic: http://forum.goldensunhacking.net/index.php?topic=135.0 (http://forum.goldensunhacking.net/index.php?topic=135.0)

To switch class do this (yes, I'm quoting myself)

Quote from: Zach on 08, June, 2009, 10:45:00 PM
Just remember this, when you switch classes, their requirements will swap. Example: I switched Felix's/Isaac's base class with the apprentice class. That makes the apprentice class exclusive and the Squire class available. However, in order to get the Squire class, Felix/Isaac had to equip a jupiter djinni to get the Squire class

Now if you were talking about my post, please do elaborate

On second thought, it may be possible that the game is checking what elemental Psys they have, and making it available to those characters? Because in my hack, the Pilgrim (wind) class was given Jupiter Psys only until its 3rd stage, at which point it learned the Beam series and Rising Dragon (fire).

Yeah, that was the initial findings... Those values DO have something to do with classes, that's for sure, but apparently it's a LOT more than that.  If it was those values alone, my experiment with Felix and Sheba, swapping their element levels, would have worked.  But for some reason, it... well, didn't.  Instead of having the classes I made for them, they SWAPPED classes (which kind of pissed me off... I worked for a while on those!).  And I mean ALL classes.  I could make Sheba a Brute, and Felix a Pure Mage.  Funny, sure, but not the desired effect.  I was hoping that I could pull that off, and then after more experimenting I could find a way to make it so that we could just change the elemental order of team two in order to create the new classes... No such luck.

Well, I found something that we CAN do!  And something that I really, REALLY like.

Item Classes that change depending on what element adept equips them.  That's right...

Let's say you want to make an 'uber attack mage' type class.  It uses the Grand Grimoire class item.  However, it's a MONO ELEMENTAL CLASS - basically, it grows in similar nature to base classes, requiring all of a single elemental djinn.  Here's what I did:

I took the Tomogathericon (class value 17) and made new classes (okay, test classes) for each element.  Each class line has 4 classes in it.  The base element level you need per type is 5, and adding 3 grows it by one.  To test to make sure it grew correctly, I started with the first class in each tier knowing two of the weakest psys.  Each class after that ups by one level for that psy group (so if the class improves, Flare becomes Flare Wall, for example), and the final one gains one more psy.  This shows that the class is progressing properly.  Another interesting thing it does is allow another adept to access the first two classes in any other element by adding between five and nine djinn of another element.

At least, that's what it was in theory.

Best part?  It works in PRACTICE, too!  I tested it, and it worked perfectly - the same item gave four different class progressions!  Worked.  Like.  A.  CHARM! :heart:

If you're going to use an item class in this manner, however, I will recommend AGAINST making it too complex.  If you do that, you'll run out of room for more classes!  So be careful how you approach it.

Still, it's nice to finally have one of these tests actually WORK (even though it was an item class). ^-^

So, Classes have covered psynergy/level requirements, how to get them, djinn requitements, element levels, and stat changes... Is there anything else that classes should influence?

Off topic for a second, is there any way to give someone a permanent psynergy, kind of like how Piers always has Douse? Perhaps it has something to do with base classes? Probably not though.

Have a nice day.

I still haven't discovered where that happens.

Would you be so kind as to tell me exactly how you did that? I'm trying to do it with the Mysterious Card, but I'm not having any luck.

I think what Role did was to get the desired item, make the desired classes, and switch the numbers around (with the Mysterious card, the value for those classes would be switched with your new classes, so the item would give you the new classes, instead of the classes which they normally give).

It would still be nice to know how to create new classes without having to change the ones that an item bestows, but I have a feeling that those three items have scripts which enable this?

Have a nice day.

Problem is, I did just that, and am getting ? classes OTHER than the ones I made, despite the fact that the ones I made are the ones with value 15, the value of the Mysterious Card classes.

Hm... Well, sorry then, I can not think of any way to help right now.

What if you list the exact steps you did in order?

Have a nice day.

I think you have to change the required elemental levels of the first class. For example, the pierrot class has no requirements, so that automatically takes priority over any other class. You have to make it so that the element requirements for that first class is not 0.

I did, I set the requirements for the original class to 100 for each element. Instead it used the WRONG CLASS!!!

Strange. You're right. I guess you can't do the same thing with the mysterious card.

I made it work. Check the five ? classes before pierrot. If you were using it on Felix, those spots had the same id as the mysterious card, while having the normal elemental requirements for the squire class. That could be your problem.

Strange, they aren't there for me, and I also tried it on Sheba with no luck.

Edit: I fixed it! XD I'd created the problem myself XD.

I just tried it on all the characters, and it works out fine for all of them...

Check to see if you have any ? classes that share the same requirements. Right now, I can see that as being the only reason why it isn't working.

^see edits for reason why it was busted. XD now I feel like a moron.

From what I've tested so far, any number in the top box of the class editor except for the one's Role listed ( 1,2,6,7,12,13,14,15,16,17) will always result in a NPC class.

Another thing I have found: The base class does not always take precedent over other classes. If you use the same number in the top box as a base class, and create a whole new set of classes with the same requirements as the base while leaving both active, the newly created class seems to be of a higher priority than the old ones.

Quote from: whizkidhvq on 08, February, 2010, 11:29:07 PM
I think you have to change the required elemental levels of the first class. For example, the pierrot class has no requirements, so that
automatically takes priority over any other class. You have to make it so that the element requirements for that first class is not 0.

Yeah, I've already said that in an earlier post, except you have to change the required elemental levels of that whole class set.

Quote from: JamietheFlameUser on 08, February, 2010, 11:38:30 PM
I did, I set the requirements for the original class to 100 for each element. Instead it used the WRONG CLASS!!!

That's because you far-exceeded the requirements to use a class. The maximum number you can have, if I remember correctly, are as follows:

Base Class: 13
Dual Elemental Class: 7 of one element and 7 of another element
Tri-Elemental Class: 4 of one element, 5 of another element, and 4 of another element
Item Classes: 3 of every element

Quote from: whizkidhvq on 09, February, 2010, 12:10:20 AM
I just tried it on all the characters, and it works out fine for all of them...Check to see if you have any ? classes that share the same requirements. Right now, I can see that as being the only reason why it isn't working.

Anything named ? are usually empty unless you filled it in with w/e yourself

Quote from: JamietheFlameUser on 08, February, 2010, 10:24:28 PM
Would you be so kind as to tell me exactly how you did that? I'm trying to do it with the Mysterious Card, but I'm not having any luck.

You have to make a class for EACH ELEMENT with a Class variable equal to that item's designated variable.  For mysterious card, this is 15.  Then you have to make classes with the following requirements:

:Venus: / :Mercury: / :Mars: / :Jupiter:

5 / 0 / 0 / 0
8 / 0 / 0 / 0
11 / 0 / 0 / 0
14 / 0 / 0 / 0

0 / 5 / 0 / 0
0 / 8 / 0 / 0
0 /11 / 0 / 0
0 /14 / 0 / 0

0 / 0 / 5 / 0
0 / 0 / 8 / 0
0 / 0 /11 / 0
0 / 0 /14 / 0

0 / 0 / 0 / 5
0 / 0 / 0 / 8
0 / 0 / 0 /11
0 / 0 / 0 /14

1 / 1 / 1 / 1
2 / 2 / 2 / 2
3 / 3 / 3 / 3




That should get you not only the ability for mono-element classes, but for an additional three multi-element classes.

^ late response is late. I already figured it out, and I've already made the Mysterious Card do this. Because the original class for it sucked. I mean, backstab is the worst EPA in the game, and the Card abilities are very expensive and very suckish. And the classes' low attack values make Sabre Dance next to useless on anyone, even Felix and Isaac.

Alright, I'm finally diving into the class code to figure out exactly what's going on behind the scenes here.

As suspected the first unknown value in the class editor is derived from the character's elemental level affinity.  The game takes the character's top two elemental levels and assigns a value based on the table below.


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.

Now here's the part you're going to hate.  Immediately after this value is loaded there is a block of code that, if we refer to the value as a variable called 'classType', basically translates to this:
if classType==2 && character==Jenna
{ classType=13 }
else if classType==6 && character==Piers
{ classType=14 }


I'm still working my way through the rest of the code, the next chunk looks like it deals with the class changing items.  From a quick glance it appears to use the specific index in the item list that they are stored at to identify them.


EDIT:
It's also probably worth mentioning how ties between elemental levels are handled in calculating the primary and secondary elements since there can only be one of each.

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.

EDIT 2:
The actual priority is reversed from what I initially said.  Thank you, Kide, for the correction.
Venus > Mercury > Mars > Jupiter.  Venus always wins in a tie, and Jupiter always loses.

So I'm guessing the patch that would be needed to give all the characters their own classes would check to see if the character is Felix, Jenna, Sheba, or Piers, and if it is, assign new values? 

Say, if character is one of those four, then class type += 12?

For their multi-elemental classes as well?

Of course.  That would prevent having problems like with Piers.  If we can have two sets of classes, we can build them so that they fit their respective teams.  This way, Piers can stay a fighter instead of being stuck as a mage, and Jenna can be a mage, instead of being stuck as a fighter.

Only Item-classes wouldn't be affected.

Okay, to make it clearer as to what I'm trying to do, here's this:

Team One (Characters 0-3, argument += 0)


Arg 12 = NPC, 0/0/0/0

Team Two (Characters 4-7, argument += 12)


Arg 23+ - Item classes.  Each argument assigned to a specific item, that item grants the classes with this value.  Overrides other values.

Quote:Venus:|  :Mercury:|  :Mars:|   :Jupiter:|
:Venus: 1| 8| 4| 8|
:Mercury: 3| 6| 3| 10|
:Mars: 4| 9| 2| 9|
:Jupiter: 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.

Just to make sure, how again does the NPC (12) value fit into the chart (other than being a declared command)? The reason why I ask is because Isaac has the level required to be a Squire, yet his one Mercury djinni makes him an NPC (yet that value is 3, not 12). It is because his Mercury level overpowers his Venus level, yet Isaac does not have the requirements for any of the other classes, right?

Also, do you know what the bottom two unknown values are (or have I just been unable to see them)? For example, 15391 for the Squire series?

Have a nice day.

It could be that he meets no Element Level requirements for any of the value 3 classes.

I think you are right about that. Luckily, I found a way around it, so Isaac can still change classes while not affecting Felix' ability (although his base class is no longer his alone though).

So, now that I think about it, is there anything that we do not know about classes anymore?

Have a nice day.

We do not know if my patch idea will work.  Atrius, any news on if it will?

I haven't had a chance to try it yet, but I don't see why it wouldn't.

If it works, let us know.  Add the patch option to the update and let us beta test it to work out any kinks that show up.

So now that this is solved... should it be unpinned?

Good call, though I'd still like to know what the other unknown value does.

Ah, alright then. What do those values affect anyway? They don't have an effect on class do they?

They're stored with the rest of the class data, I can't imagine they'd affect anything else.

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....

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 - :VenusStar: 3  :MercuryStar: 5  :MarsStar: 3  :JupiterStar: 0
Tier 2 - :VenusStar: 4  :MercuryStar: 5  :MarsStar: 4  :JupiterStar: 0
Tier 3 - :VenusStar: 5  :MercuryStar: 5  :MarsStar: 4  :JupiterStar: 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 - :VenusStar: 1  :MercuryStar: 5  :MarsStar: 1  :JupiterStar: 1
Tier 2 - :VenusStar: 2  :MercuryStar: 5  :MarsStar: 2  :JupiterStar: 2
Tier 3 - :VenusStar: 3  :MercuryStar: 5  :MarsStar: 3  :JupiterStar: 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 - :VenusStar: 1  :MercuryStar: 5  :MarsStar: 1  :JupiterStar: 1  Class Type: 8
Tier 2 - :VenusStar: 2  :MercuryStar: 5  :MarsStar: 2  :JupiterStar: 2  Class Type: 8
Tier 3 - :VenusStar: 3  :MercuryStar: 5  :MarsStar: 3  :JupiterStar: 3  Class Type: 8
Tier 1 - :VenusStar: 1  :MercuryStar: 5  :MarsStar: 1  :JupiterStar: 1  Class Type: 9
Tier 2 - :VenusStar: 2  :MercuryStar: 5  :MarsStar: 2  :JupiterStar: 2  Class Type: 9
Tier 1 - :VenusStar: 1  :MercuryStar: 5  :MarsStar: 1  :JupiterStar: 1  Class Type: 10
Tier 2 - :VenusStar: 2  :MercuryStar: 5  :MarsStar: 2  :JupiterStar: 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.

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

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...

Quote from: Kide on 20, November, 2011, 01:58:06 PM
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.

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.

QuoteI'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.

Quoteit 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.

QuoteYou 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.

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?

Quote from: Atrius

	:Venus:|	:Mercury:|	:Mars:|	:Jupiter:|
:Venus:	1|	8|	4|	8|
:Mercury:	3|	6|	3|	10|
:Mars:	4|	9|	2|	9|
:Jupiter:	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.

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").

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

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

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.

Quote***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. :happy:

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.

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

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

Quote from: RoleAll 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 :VenusStar: 5.4  :MercuryStar: 3.2  :MarsStar: 3.3  :JupiterStar: 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.

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:  
(http://i14.photobucket.com/albums/a314/acidadept/TestResult.png)
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.

(http://i14.photobucket.com/albums/a314/acidadept/TestResultB.png)

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.

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

Well,

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

Quoteyou 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.

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?

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.

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

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

Huh...  Ability effects you gain a 25% chance to perform?  I didn't see that one coming.

Thanks for the information again, Teawater.  You've proven to be quite a big help on the hacking end of things.

Edit: NM, stupid.

So it increases effect rate of some skills. THAT's certainly useful.

And in the enemy section... would that be immunity to some effects?

QuoteWait, so any time you attack you have a 25% chance to activate those abilities?

A 25% GREATER chance than its base value chance.

QuoteAre they given as secondary effects to your regular attack, or what? Is it just the ability's secondary effect?

It's when you use an ability that has the listed effect. If it is listed, than the ability gains a 25% success rate. I don't think there is anything secondary.



P.S. And whoops, almost missed y'all's post, due to my post being at the end of the page. I also want to note that you know how there are two "May inflict stun"? Well, I think the second one gets three checks for success, just like two others. (I edited my last post.)



I am also still researching the code to see if we can somehow give enemies classes. Edit: Since that's the one thing that puzzles me about this right now.



Edit:

QuoteAnd in the enemy section... would that be immunity to some effects?

Actually, I think those are weaknesses to some effects...  (Edit: It is still part of the 25% greater success rate.)

QuoteI am also still researching the code to see if we can somehow give enemies classes. Edit: Since that's the one thing that puzzles me about this right now.

I don't believe so.  I think the closest thing is the 28th byte in enemy data, it's used to assign the elemental values displayed at the bottom of the enemy editor.

Enemy data: 0x080B9E7C
Enemy Elemental data: 0x080C6684

You obviously missed my edit. And yes, number 85 seems to have a higher success rate than number 23. And now we need to go check and see if Avimander has a weakness to 23 and 85, since he seems to stun easily.

Okay, than I have a question.

I know that 02030A12 is based on the Enemy number (it is off by 8, I know.), but it seems like the class value is supposed to be at 020309F1? But it is 0, so I was wondering if there is any way the game changes that value...


Edit: Actually, maybe it does use the character's class value in that function, I need more research... I mean, with one of the args being the data pointer, couldn't it work both ways? Edit again: That also explains why the enemy numbers are off by 8, the player characters are those.

Hmm, this is very interesting... keep up the good work, guys - anything which helps refine the editor is great in my book.

Still... This is about abilities, right?  I'm not certain how it ties to classes, or did I miss that part?

Oh yeah, you must have missed that part.

I posted here with the intention of explaining the unknowns in the class editor only to find out that the ones in the Enemy Editor were also related.

Anyway, I think I know now.

Class Editor Abiltity Effects = The enemies get the 25% bonus chance of success when using an ability on someone of the class that has that ability effect listed.

Enemy Editor Ability Effects = The characters get the 25% bonus chance of success when using an ability that has an ability effect losted in the Enemy's weaknesses.

I think this is how it works? It would also explain why the enemy numbers are off by 8.. (0 - 7 are the player characters.)

Wait, so the numbers at the bottom of the class screen refer to specific abilities?  So it's basically ailment weakness or something like that?

They refer to ability effects Not abilities themselves. The abilities which are being used should have the matching ability effect for the 25% bonus.

Huh...

I think I understand what you mean...  Still, just to make it clearer, can you make a visual aid?

Circle the value you're talking about, explain what the number refers to and point out which effect it's calling.  Also, are there some classes that resist an ailment, or is it only vulnerabilities?  Do some classes have multiple weaknesses or strengths?

Once you fully figure this out, a guide to understanding how it works and how to use it would come in really, really handy.

I see where the values are for enemies - between the ability slots and the coin value. However, I am a tad bit confused for how it works for classes. It would appear that the editor has them listed as shorts, but it seems like they should be bytes instead. Their effect weaknesses would end up being quite different depending on which they are:

Bytes: 3340 becomes 0D0C, should be 0C 0D, which becomes 12 and 13. This means that a class value of 3340 would make these classes vulnerable to defence lowering attacks (such as Impair and Debilitate).
Short: 3340 contains two effects, and this seems to be Confusion and Death Curse. However, this option doesn't seem to make any sense in the long run...

My best guess is that they are bytes instead of shorts.

Oh, and did I explain this accurately? I might make a guide later if I did.

Ah, so it's a weakness rather than a proficiency. Does Avimander have weaknesses to Effects #23 and #85? Would explain a lot if it did.

I was beginning to wonder why enemies would have ability effects set that they would never use themselves.


As for the enemy numbers being off by 8, the pointer that I gave you is the pointer that the game uses the majority of the time.  I had noticed there were 8 entries before the main list, and suspected it might have had something to do with the PCs.  It's impossible for the game to use those slots for enemies though since the way it normally looks them up those slots would have negative indexes, and I couldn't figure out what they were used for so I've pretty much ignored them up till now.


@Salanewt, yes they are bytes, but the editor displays them as shorts right now.  This will obviously need to be fixed.

Quote from: JamietheFlameUser on 02, January, 2012, 09:51:20 PM
Ah, so it's a weakness rather than a proficiency. Does Avimander have weaknesses to Effects #23 and #85? Would explain a lot if it did.

Remembering that you use a Mac, I take it you do not have access to the editor.. Mmmkay... It says:

90 - Avimander = 12, 13, 24

12 - Drop Defense by 25%
13 - Drop Defense by 12.5%
24 - May inflict sleep

I assume that is correct.


Edit:

QuoteIt's impossible for the game to use those slots for enemies though since the way it normally looks them up those slots would have negative indexes, and I couldn't figure out what they were used for so I've pretty much ignored them up till now.

This may be true as long as the comparison that checks if it is a PC or an enemy is made..., otherwise you'd get something like this...


r0 = 08001000 (just a random number)
r1 = FFFFFFFF (Say this is Piers. 7 minus 8)

Pretend there is like 0x10 data per an entry for something.

r1 << 4
r1 = FFFFFFF0

ldr r2, [r0, r1] //You can add negative numbers, you know. (Ex: 08000FF0)

08000FF0 (FFFFFFF0) = Entry 7
08001000 (00000000) = Entry 8
08001010 (00000010) = Entry 9