Advanced Ability Accessibility (better name pending) Concept

[Salanewt]

Howdy. So uh, yeah. Following a small chatbox discussion with Fox, I decided to make a post about something I'm planning out. If I do it, it would basically let characters learn spells depending on a number of factors, such as item, class [restrictions], character ID, current level, and eLevels. This may look very similar to the existing class system on paper, but the idea is that it would be much more flexible (and if this post doesn't convince you, then I may add it to Disco Sun eventually).

I'll use Piers as an example. His base class basically gives him access to spells like Frost and Cool, right? In the standard class system, giving him a djinni of any other element would strip him of those spells and force him into a new class. In this system, spells would be based more on his eLevels than class; giving him a Venus djinni may give him access to a spell like quake while still keeping those other ones available, or it may not if the new class is "restricted" in that regard (such as being unable to learn the spell if in any of the item classes). However, it goes a little beyond that; this system would also allow you to have item and character restrictions, so Mia could be barred from learning it despite having the same eLevel combination as Piers, or maybe she has to equip an item before she can learn it at all. Additionally, this would allow one to potentially have an item teach a whole line of spells, like in Dark Dawn, or even items that only teach spells if you have the right level/eLevel requirements.

So yeah, this is what I have so far. I still have to work out a couple of the details with the item requirements and stuff, but I think I have the basics covered at least. Keep in mind that the standard class system would still be in place, and the code would check to see if you have a spell or are about to get it from a class before trying to teach it to you. In fact, this would basically let you bypass the 16 ability-per-class limit (if care is taken to avoid the ability cap). Also keep in mind that, as far as item requirements go, you can still decide whether certain characters can or can't equip an item that is listed in this system.

Code idea (class system hybrid): This new system will teach spells depending on elemental level and regular level, but can also teach or restrict spells depending on
character, item, or class ID; old class system will complement this new code and still function the way it already does on its own

0 - If spell ID matches existing spell (not in bank), end; if not, continue
2 - If item/equipment matches (base ID for "item flexible," + x1000 for "item required," + x2000 for "item absolute"); "flexible" skips to character if
    equipped; "required" will end if the item is not equipped and skip to character if it is; "absolute" skips to level if equipped.
2 - Compare class IDs (relative pointer to list, which disqualifies any classes that match and ends with xFF; x7F will count all classes between a and b by working
    as a <= operator); branch and continue or end accordingly (no relative pointer defaults to "can learn in any class")
1 - If character ID matches (binary; 0 = failed check, 1 = match), continue; if not, end
1 - If level >=, continue (will be somewhat different; "positive" match will check for eLevels, "negative" match will just grant the spell); if not, end
2 - If eLevels match (compares 4-bit values to Venus-Mercury-Mars-Jupiter values in RAM), loop until all checked and >= bank values and then grant spell; if not, end]


Will need to be linked from class, equipment (maybe bestowable), and djinni/eLevel updating functions at least; also for when the player actually levels up.

080B0298 = Djinn set/removal calculations (grabs/updates class ID (possibly abilities too)? and links update_elemental_pow_resist)
080AF4B8 = psy_check(party_member, ability) as Boolean //Returns True if s/he has the ability.
080AF6F4 = add_ability(party_member, ability) //Returns an ability_slot


Pseudo-entry (e.g. Clay Spire)

1064 0020 C9 14 4000

- Requires item #100 (x1000 would mean that you must have "nothing" equipped, effectively skipping the entry)
- Reads data at x20 from base address...
+ x20:  01 7F 05 FF
- ...and with this pseudo entry from another table, characters can't learn the spell in classes 1-5
- Converted to binary, only characters 1, 2, 4, and 7 can learn this spell
- Must be level 20+ to be able to learn the spell
- Rearranged accordingly, one must have a Venus eLevel of at least 4 before this spell can be added

And this is what I'm mulling over. I'm definitely open to input, since it would suck to forget some crucial detail or even clutter the code up with useless checks. One thing I definitely need to do before I can get a good start is make a list of every function I will need to branch to or from, so some pointers in that area would be terrific as well.

So yeah, study time!

[Luna_blade]

Sounds already like a great patch!

I'm not so sure what can be done and what can't be done, but I thought it was pretty strange that a GS Character didn't need to learn all the spells from all the classes individually.
So Ivan for example still needs to learn Haunt in Medium class if he leveled up to 17 in another class.
However learning Haunt in the Medium class also unlocks it in the Enchanter class.
But I guess that's not good for late game, since there are more classes available and you would need a lot of catching up to learn every spell of every class.

I guess the hardest thing you're trying to do here is deciding which spell needs what etc.

[Salanewt]

1: Thanks! I just hope it does turn out to be great when/if I do it.

2: I see what you mean. Something like that would probably be easier if not for the ability limits that the PCs have; I think it's about 32 if I remember correctly. They could probably have handled the different leveling stuff a bit differently as well.

3: That would be a part of it, although a fair amount of it should be simple enough. The main think I would like to do before I attempt it is make sure nothing is overlooked (i.e. the ability to pick which classes you can't be in, which would have an argument that allows you to set a range of classes rather than setting each one individually), while also avoiding duplicate checks or putting too much effort into the more trivial aspects this system.

[Caledor]

While this could easily become one of the most interesting patches to the game, I think that you could reach the same result in a much easier way by turning the whole thing into a TRUE class separation patch (a different set of classes for each character). At the moment we can't do that only due to space so why not reallocating the whole class section later in the rom and use something we already have (code-wise) instead of creating something entirely new?

[Salanewt]

Well, the idea with this is to separate a lot of the spells from the class system and change it up a bit. For example, if I have a character in a tri-elemental class and give them a djinni from the off element (for example, Mars in the white mage class), then the character in that class could potentially learn a low-level fire spell or something without changing classes. It would also allow one to learn spells between class tiers, especially the item classes which normally require three djinn per tier and are available pretty early in the game.

It's funny how you bring up the class expansion/separation stuff though, since that's one of the things that gave me this idea. Well, that and how boring class creation is. The abilities that the different classes can give you are normally pretty arbitrary though, and it would be more flexible to go "you can't use that spell in classes A, B, and C" rather than "you can only use that spell in classes A, B, and C." Separation itself is pretty simple (especially when each character can only fully access about six lines of anywhere from 2-6 classes), but doesn't quite offer what I'm hoping this system may. Well, should I make it that is.

[Daddy Poi's Oily Gorillas]

Hm... Interesting. I'm guessing this could easily be effective for the Innate Psynergies as well.

If you turn it into some type of commands and args system, I can see having conditions for any PC data, perhaps.
Like if your Agility was high enough, maybe you could have some Ninja/Stealth-related abilities...
Perhaps even have a condition for when you are poisoned... (For example, make Cure inaccessible to the poisoned PC?), and so on.

One of the commands could be a flag check. (Ex: A story event where an NPC might teach you a psynergy. Although, I know that Psynergies can become added like Innates at Rocks, but this helps add another usable bit for each psy slot, I guess. With more customization if it happens to be that such a psy has other limits as well.)
Another one could be a map/door check. (Ex: Being close to a Lighthouse or Rock could offer additional psynergy.)
Just to point out that there are plenty of things you could base it off of. (Some are probably not necessary.)

[Salanewt]

That too, yeah. Something like this could even make it possible to have a character's innate spells change depending on their element/class setup (i.e. Move gets swapped out for Carry if changing from a pure earth to a mixed earth-wind class). I imagine it could be set up so most bestowable rocks are more optional, granting the ability to free up inventory space without plopping every utility onto a character or class. The system would be pretty open in that regard.

Also, those are some pretty cool ideas! Most of them might be a little too niche for this, but I'm planning on leaving some empty space in the code where one could easily set a lot of those up if they want. I'll probably do the same for the table itself, since having a flag check could be immensely useful as well; I can't believe I never thought about it earlier, so thanks for pointing that out! The flag check should probably come before the item one, and I can set it up so whoever else may use this can decide which flag to set as the "skip flag check" value. I guess it should take up two bytes as well...

Awesome!

[Daddy Poi's Oily Gorillas]

You are welcome.  Hmm... Basing it off a flag might mean the best approach for calling the functions that sets up which abilities you can access is when you go to see the psy lists, or when you use a shortcut. (L/R) With this method, I can see it possible to get rid of the psy lists in the PC data altogether, and have the lists generating in the 02030000 section (Or you may not even need to generate lists at all?). This could also help get rid of the PC-based psy quantity limit. (Depending on how you code it.)
(At least, I think that would work until you decided that psynergies are limited based on how often they're used? And/Or if you have manual in-game psy-swapping much like the djinn system or something?)