I don't know if YEP handles this, but still, if you have to use a plugin to modify this, I would still say it is impossible without a third-party plugin to modify this behavior
That's fair enough, but I think everything we're discussing here would require plugins to implement, so that's why I raised the query at "impossible"
You'd just use Skill Core to put a Cost Display Eval notetag on the skill and set a variable on the actor, e.g.
That will execute when the player mouses over the skill, so definitely before it gets chosen and performed. Then you can just reference the value later in your damage formula or action sequence.
Now imaging if you could only add 5 of these to the spell at a time.
How would you as a dev do that?
For me, I'd do it as was described earlier - everything you describe there can be done using the Yanfly Engine.
The Skill Core has cost evals to handle that portion. Action Sequences and the Element Core can add elements and states in conditionals, as well as display whatever animation you like. The only part of it you'd need to write anything separately for are:
- Modifying the skill's displayed name, and that isn't terribly difficult
- The actual interface for how you're applying the runes, unless you can shoehorn an existing plugin (like the Materia suggestion above) into it. I think the Materia system explicitly works by giving new skills, though, so you'd have to look into that in more detail.
I'd love it if each actor could have multiple spells like this at their disposal
This is the only real trick. If you want them to have multiples of this, you're going to have to make this all more complex in some way.
Either by taking the conditional stuff out of the skill and splitting it into tons of skills in your database to reflect all possible permutations, or by creating some kind of independent item version of skills to allow and handle actors knowing the same ID more than once and coding the framework and interface for that.
Or at least you choose a particular degree to implement with different IDs and do the rest as described above. So maybe you can have both a fire blast and a water blast, but that's it - all other modifications to a fire blast are still a fire blast and an actor can only know one. That way they'd be able to learn multiple blasts but you only have to take up a few different database entries.
Everything else you describe is potentially a fair amount of time to create, but fairly straightforward in its implementation.