Post by Ramza in MV - Shield Block comments

Viewing post in MV - Shield Block comments

Hello there.

Unfortunately, those functions from YEP_ExtraParamFormula do not work with block or parry at this time. Block itself was actually causing a crash when used with that plugin specifically because of an issue with it where it wasn't expecting there to be more than 10 xparams in the first place, and didn't define default values for xparam(10), which caused crashes on load when it tried to read paramPlus values and such for that eleventh xparam.

Technically if the yanfly plugin had not made the assumption that there were only ten xparams, adding something like this two it would just be a couple of extra lines defining a couple of new functions, and using their existing functions to make it happen. It could be doable without much trouble, but I think it's a bit outside of the scope of my plugin here though.

~Ramza

zelanius2 years ago (1 edit)

Hi Ramza, thanks for the response.

To get around the xparam limit issue, would it make sense to create a new param naming for the block and parry chance? It might be outside the scope of the plugin, but based on my experience after trying out various param plugins, that seems to be the approach most custom param plugins take.

Nonetheless, I think I figured out a workaround. Since Block Chance requires a state anyway, I can just have the same state check if the user of the shield has a certain Skill ID and if yes, adds the Block Chance automatically, while for Parry Chance, I believe I can try the same using the plugin's Extra Parry Chance formula.

Ramza2 years ago

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]

_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

zelanius2 years ago

Hi Ramza,

The dozens of passive states was the main issue I had, as I had over 100 learnable, but functionally similar, passives, as they are basically higher levels of previous ones. I scrapped my almost completed game to overhaul my skill system, and so far it seems successful. I just need to figure out how to implement them properly without states.

In case anyone is interested, I just did the below in the Parry Chance plugin under the additional parry chance function, where skill ID 877 is the level 2 of skill ID 876, and you need to learn 876 before 877:

var a = this
if (a.skills().contains($dataSkills[876]) && a.skills().contains($dataSkills[877])){ 
+0.25 
} else if (a.skills().contains($dataSkills[876])) { 
+0.1 
} else { 
0 
}

Now, I just need to figure out how to do this for Block Chance.

zelanius2 years ago (2 edits)

Hi Ramza,

A followup question, if you will. Is it possible to input formula into the plugin parameters for Block Percentage to add to the equipped shield's Block Percentage? If yes, I tried the following but none seems to work (I tried both this. and a.):

this.skills().contains($dataSkills[874]) ? +10 : +0
this.skills().contains($dataSkills[874]) ? +10 : +0;
if (this.skills().contains($dataSkills[874])) {+10} else {+0}
if (this.skills().contains($dataSkills[874])) {+10;} else {+0;}

Not sure if I am doing anything wrong in any of the above lines. Greatly appreciate your response, and thanks in advance!

Ramza2 years ago

Hello.

Unfortunately, there is currently no way to conditionally add block rate to a battler. The notetags on database objects are parsed into traits on the objects they are found on at the time the database is loaded, meaning even if those tags were designed to take a conditional statement like that, the condition would likely be false.

Like with other xparams, such as crit % or hit %, the only way to add more of them is to put them as a trait on either a state, or equipped item. Because traits can't take a variable as their amount, the only way I envision this working is via passive states on those skills.

As mentioned, passive state bloat is a thing, and it's not ideal, but there is currently no other way to do it, as far as I'm aware.

It might be possible to patch the YEP_ExtraParamFormulas plugin to allow it to work with block rate in the same way it works with the other xparams. Similarly, adding base and "extra" block rate parameters to the block plugin could also be possible, but doing so would require me to essentially do exactly what the extraparamformulas plugin is already doing, likely with some awkward interactions between the two of them.

~Ramza

zelanius2 years ago

Hi Ramza, thanks for the response, but in the plugin itself, we can add block value and percentage, right? I was wondering if we can apply a code in the existing parameter instead of a flat value to add the amount of damage blocked

Ramza2 years ago (1 edit)

Not presently, no.

As with all note tags, their values are parsed when the database is first loaded, so even if a conditional were possible, it wouldn't be parsed correctly.

On the other hand, block percent and block value are calculated only when they're needed, and exist solely on the shield that is being used to block. You can see from the exparamfix patch, how that is calculated:

case 'blkp':
    this.drawAttributeName('Block Amount', dx, dy, dw);
if (this._actor.isStateAffected(Ramza.BlockParams.blockStateId) && this._actor.equips()[1] && this._actor.equips()[1].blockPercent){
    this.drawAttributeRate((this._actor.equips()[1].blockPercent / 100), dx, dy, dw);
} else {
    this.drawAttributeRate(0, dx, dy, dw);
}

The default block state also uses those same values from the shield in the damage calculation:

var blockValue = (target.isEnemy() ? target.enemy().blockValue : target.equips()[1].blockValue)
var blockPercent = (target.isEnemy() ? target.enemy().blockPercent : target.equips()[1].blockPercent)

You could modify the state directly to change those values based on your skills.

edit:

blockValue is a flat number, and blockPercent, at the point I pasted it there is also a whole numbers which is removed from 100% later in the state calculation. You can conditionally add numbers to it in the state in the same way you posted above. Use 'target' as the object, not 'this', and it should work.

~Ramza

zelanius2 years ago (2 edits)

Hi Ramza,

Thanks again for the response. I did think about using the Block state to provide the additional block percent, but the main problem is that this does not show up in the status menu, so my issue was more of an aesthetics reason rather than a functional one. Nonetheless, if there is really no other way, I will just do it by creating a new state. I should not have too many people being able to use Shields in my game so it will not blot the game unnecessarily. I was simply going to the (perhaps unnecessary) extreme to avoid creating new passive states after my last experience game making experience.

itch.io

Viewing post in MV - Shield Block comments