Evening, @Yanfly ; hope things are going well! I noticed a couple really unfortunate interactions in your scripts recently (Centering around the Class Change scripts), that I figured I would bring up here in the hopes you would be able to address them. Part of this may be deliberately intended behaviour, but I'm going to list the full implications discovered and why it's an issue; if this has been discussed before, my apologies; 2900 posts is a lot to dig through. Anyway, it all centers around how swapping classes handles skills. Class skill access is a bit weird. When swapping classes, the characters actively retains all of their learned skills in other classes (This is the part that seems probably intended). Let's say a character learns Heal from Cleric, which is classified as a Magic command skill. Now you swap to Wizard, which also has the Magic command skill. The character will still be able to cast Heal, even though they're not part of the Cleric class. This is... frankly, not exactly desirable. It's likely deliberate, which, okay, fair. There are two workarounds that can be used. I'm going to explain where each of these expose various issues with the scripts as they currently exist: Solution one, we can make use of the subclass system's Require Class/Require Subclass skill tags. Curiously, this ONLY exists in the Subclass system, requiring the plugin to at least be installed for this. Unfortunately, this system has a problem. Suppose for a moment, that I have three classes: Warrior, Cleric, Wizard. Each of these classes has access to the Magic command set. I want Cleric to be able to learn Heal, and then will use the tags to require Cleric to be present in order to be cast. So, this is what happens: If I use neither Require Class nor Require Subclass, then any combination of classes that has access to the Magic command can now cast Heal. ...What? If I use Require Class alone, then any combination starting with Cleric works. Cleric/Warrior, Cleric/Wizard, Cleric solo. Good. This works as intended. If I use Require Subclass alone, then any combination ending with Cleric works. Warrior/Cleric and Wizard/Cleric work. Cleric as a primary class does not. This is... it's awkward, but okay, there may very well be times that this is the specifically desired interaction, so I won't say it's not working right. The problem comes when... If I use both tags to require Cleric, then... nobody can use it. Ever. You literally can't set Cleric/Cleric, and that's what the system insists on. So, Issue #1: There is no situation, using the Require Class/Subclass skill tags, whereby I can require someone to use a specific Class as either a Main or Sub class in order to use the skill. There is no functional overlap. It would appear that using both tags at once does not create an 'either/or' effect, but rather requires both conditions to be met. That's... well, it's awkward, to be honest, and seems a pretty significant oversight. Relatedly comes Issue #2: Even when I do use these tags, skills are simply 'grayed out' (unselectable), not removed entirely. It seems really, really strange to me that Heal is sitting on my menu at all when I'm in Warrior/Black Mage. There may be a way using Skill Core's Lunatic Mode to solve both #1 and #2, but that is A. messy, B. not something I seem to be able to find the exact right syntax for to make it work, and C. a bulky solution to what should be a problem with a common fix imo. So, the tags are less than ideal. What next? Well, the other solution, is simply to make each set of skills attached to a different Command set. If Heal is attached to "White Magic", and Warrior has "Battle Magic" and Black Mage has "Black Magic" instead, problem solved! Besides, it looks nicer that way. ...Right? There's two times, however, where this becomes a problem. The first, mostly minor, is if there is good reason to use a shared command set. For instance, if I want every class to have "Limit Breaks" that use TP, then it would make sense to have one set called Limit Breaks. Unfortunately, because of retained skills, then Limit Breaks from other classes would remain. Having multiple similarly named skill sets would be an awkward, but functional workaround (A "Limit" that consists of just Cleric LBs; and another "Limit" that consists of just Black Mage LBs, etc) - until we also inherit skill sets from subclasses, in which case now suddenly our character's got two skill sets listed as "Limit" and just... eww. As demonstrated, the Requires Class/Subclass skills also have a rusty limitation above working around it in a shared command set. The second problem though is that the skills are still there regardless, and this actually does matter. Where does this become a problem? Well, aside from the visibility issue (Again, why should I be seeing skills I can't use in a given class?), there's a bigger problem: Auto Passive States. Let's say that Warrior learns a skill called "HP +50%". It's attached to a passive state that permanently boosts my max HP by 50%. Cool, right? Yeah, great. Except that now I swap back to Black Mage, and... suddenly I still have the 50% bonus HP. Because the skills are still being known, the passive states are still being applied. Which leads us to Problem #3: Interactions where simply posessing a skill is enough to trigger something (eg Conditional Branches, application of Passive Skills) don't care that they're from a completely different class; the skills are present regardless and therefore function. And again, there may be some Lunatic Mode passive skill stuff that could be applied to have it check the user's classes, but I couldn't find something that evaluated this successfully, and it's a messy, bulky solution. These are some pretty severe obstacles to things I was planning to do making use of these systems. I'm all for using different skill sets, which solves the majority of issues surrounding #1 and #2. Unfortunately, issue #3 is pretty seriously limiting without at least a lunatic solution. IDK. It's very possible a lot of this is deliberate design, and if so just let me know and I'll find ways to deal (Although any confirmation about the syntax to confirm an actor's class/subclass for lunatics would be appreciated); but yeah. Figured I should bring it up. For the record, the scripts used: Core Engine 1.13 Class Change 1.09 Subclass 1.07 Auto Passive States 1.07 No other scripts or modifications have been used. EDIT: I was able to figure out some lunatic mode stuff to get around this. I still think this is really messy, but I've at least ascertained that "user._classId" and "user._subclassId" can be used to check those, so I should be able to work around these if the behaviour above was entirely intentional.