Item Scripting Issues

I'm making a game (obviously) where I can change classes at the use of an item. The item in question is a stone from the pokemon games, but I ran into a stump. Say, I were trying to evolve a Poliwhirl with the Water Stone, I would like the game to check the class with a conditional branch instead of the actor. In doing so, I would like to make sure I could use the same item on an Eevee to get a Vaporeon without cross-class changes happening (Poliwhirl to Vaporeon and vice-versa). If there's any questions pertaining the game itself, it's strictly personal and for my own use, but I'd be happy to share what little I've got so far to help answer questions to my questions.

your description is extremely confusing to someone who hadn't played the same games you have.
Please describe your intended game mechanics without references "like unknown game xy", but by the facts of what they do.

Class changes by items should not be a problem, conditions there will only make the common event longer and tedious to create. But we can't point you into the correct direction without knowing what you want.

Point made. I'm changing actor's classes as they are added to the party because of the sheer number of party members you can add to your game. I'm not having Actor 0002 (and so forth) set as anyone, I'm rewriting it as a new member is added to the party. So, I would like an item script that checks the target's class, and if it's within the specified parameters, it will change that target's class to another specified one. I hope this makes enough sense.

easy but tedious - extremely tedious as that is a lot of work that increases with the number of actors and classes.

You'll need an item that calls a common event for the effect, but due to the limitations of the common events you'll additionally need a way to identify the actor using it.

1) make an invisible "target state". That state should have no messages and no icon, the player should not see it used.
2) make the item with two effects: giving the user that state and calling the common event.
3) and now prepare for a lot of work writing that event, but it will be just repeating the same commands over and over.

OK, and here begins a difference depending on your specific project. You need to decide if you make this event pure eventing or if you take shortcuts with some scripting lines.
Using event commands will make the common event better readable and easier to bughunt, but it will also make the event much longer. The key difference is the conditional branch command.

With pure eventing, you'll have to check for every combination of actor and class. With scripting you can use variables and loops to reduce that.
However, since you want different effects based on class you can't shortcut that part, only the actor part.
So how many different actors (with their IDs) do you have? If you have only a few actors as placeholders for the many possibilities, I would suggest to go by eventing. If you have a dozen (or several dozen) different actors, it would be easier to go with a scripted and variable based condition of actor-class.

Unfortunately I can't give you the syntax for that second option and have not enough time for more details.
Give your decision and wait a bit, if needed someone will come along with the script syntax or a more detailed description of the eventing neccessary.

Eventing with scripted variables was how I was thinking it would be done. The Target "Invisible" State was a thought, but I had brushed it off early on. To answer a question, I'm looking at having, potentially, about 500 actors. I'll give the State a try, and post results when I can. Easy but tedious is how I best work. I would love a specific script but I'll take whatever I can get. Also, any ideas other ideas are more than welcome.

Edit: I wanted to thank you for taking the time to respond. It's been a rough search on Google for everything so far.

Hi! I'm sorry it's been a few days, with Halloween and all. So, I found the tedious bit you were talking about and I hope I understand you correctly. With pure eventing, you would like me to check every single possible actor for the invisible state, and if it's a yes, then change that specific actor's class and then remove the state afterwards, correct? Which, with so many actors, is a lot of scripting. The invisible state idea would make this easier, but I'm still new to this. If there was a way to check the class of the one affected by the state and if (b.classID(61)) then (b.changeclass(62)). Then I'll have to figure out how to change images along with that. I'm sorry if it seems like I'm asking a lot. Again, thank you for everything so far.

there are ways to simplify that work, but it will require scripting knowledge from you.
Basically you could make it a loop with a comparison to the data to be checked - but the more complex the data is the more difficult it is to program. That goes to the point that no one can give you a guide for that code if your data is more complex, because you would have to give them the entire data before they could start to code.
And if you don't have all data ready but are creating the data as you work on the game, no one but you would be able to integrate it.

Alrighty, I got it figured out, but now I'm running into another issue. I'm using Yanfly's ClassChangeCore and SubClass plugins. When I change Actor 2's class from 1 to 2 via level requirement unlock (maintain levels is on in the Core plugin), I still have access to class 1 and I can't figure out how to prevent the actor to not have that option to go back to class 1. Furthermore, Actor 3 (which begins as class 4 and should only be able to advance to 5 and 6) now has access to class 2, and I don't want that. I want my Actors to grow in a specified branch without going back or being able to access other branches of growth/classes. You wouldn't happen to know anything about that, would you?

what happens is part of what the yanfly plugin is intended to do.
why are you using the yanfly plugin? because it might be better to use no plugin or a different plugin based on what exactly you want.

That is the main reason why I try to not use yanfly's plugins - they're usually packages and it's difficult to do something with them that wasn't intended to be done by yanfly...

Alrighty, I got it solved. I ended up locking the base branches of each class tree to an actor, otherwise this alone would take months. I made a common event on use with the item (the item being non-consumable) that brought up all of the classes (with a SHOW CHOICES branch) that could be changed with that item, then made conditional branches to check if a specific actor is that class and if so, it would change to the desired class (depending on the item) and would remove one of that item from the inventory. It's the only thing I found that would work so far. Thank you for your time.