Hello,
In retrospect, making block chance function as if it weren't an xparam at all would've been great for compatibility, and I did so with expertise and parry chance after the original block plugin was released, mostly for that one reason. The issue here is one of transparency - block (and really parry and expertise) ARE xparams, so to conform to the already built in system in RMMV, they should be defined as such too. The issue here is that yanfly (and likely others, but yanfly is the only one I've had compatibility issues with) hardcoded the extraparams and specialparams plugins expecting there the only be the default parameters. simply changing a line where it defines the addFlat bonus, for example, from
_addXParams = [0,0,0,0,0,0,0,0,0,0]
to
_addXParams = [] for (i = 0, i < Game_Battler.prototype.xparams.length; i++){ _addXParams.push(0) }
Would've made it so that it could've dynamically updated with an increased number of xparams. The problem, of course, is that with no other plugins, there's no need to do that. So is it on them to make their code more robust, or is it on me to make my code play more friendly with theirs? Or is it my job to go into their code and make some kind of patch that does basically what I did above? It's hard to say, really. For the VS plugins for MZ, the third option is out entirely, since their code is obfuscated, and one could argue that yanfly doesn't really want people doing that in the first place with the YEP plugins either, which is why they're behind a paywall now, and a big part of the reason for obfuscating their successor.
It's good that you found a way to workaround the issue. I was going to suggest that while too many passive states can bog down the game a bit, as long as you use the states you do have in an intelligent way, that shouldn't end up being a problem. Just don't have two dozens passives that all give an extra 1% and you should be fine. :)
~Ramza