Is it possible to filter the states blocked by this plugin?
Let me explain. If an enemy attacks with an ability that poisons and my hero blocks, I would like the poison to be blocked as well. On the other hand, I use a lot of invisible state for the player to trigger various effects (like recovering MP after having suffered magic damage for example). These effects are therefore triggered by states associated with all enemy attacks. I want these states not to be blocked. Is it possible to select the states to be blocked and those which should not be?
I have added that request in the latest version. I didn't do a lot of testing, but it doesn't seem to cause any crashes, and worked as intended in my test project. Give it a try and let me know if you have any issues.
Hey Ramza. Thanks again for the StatAllocation patch but for some strange reason, all of the Extra Parameters crash when allocating due to the patch. I'm assuming that might be because of Ex Parameter limit. I just wanted to give you a heads up. I may have to try to reach out to Yanfly for a fix in that regards. Thanks a bunch!
EDIT: There was a typo on line 5 of the patch, xparamsetallocationfix wasn't used on line 6, as it was a typo. I just replaced that and it worked right away
I have another question on the Block Chance and Parry Chance plugin. Is there a way to make individual weapons or shields have the chance of parrying or blocking based on a user stat's, like level, for example?
The reason I am asking is because in my game, I have, let's call them legendary, equipment that I want to tie to the user's level, to prevent them from being too over-powered if the user obtains them early. The intention of these equips is that they will be more powerful than the most powerful buyable equipment in endgame, but they can be obtained early, and some as part of the plot.
Thanks in advance!
Edit: Nevermind, ignore me, I realized YEP has no function for this for their xparam and sparam plugin either, so I am forced to fix those values anyway.
Hey Ramza. I've been using your plugin for quite awhile now and never had any issues until recently. For some strange reason, any attacks against the player and viewing the Status window, trigger this error. I have all of the required Yanfly plugins. I turned off the Olivia's Set Bonuses plugin and it crashed with that as well. I have Block and DW (with menu extension) under BattleEngineCore, and exparamfix under AutoPassiveStates. I followed all of Yanfly's load order to make sure I had things in their correct place. I'm not quite sure what happened.
Block State is the same code as you have here, I changed plugin parameters to match my State ID, I copied the animations from your project just to make sure it wasn't that. So I'm not sure what's going on. Any help would be appreciated.
EDIT: I have discovered the cause is StatAllocation. Not sure how to get around that as that is a crucial plugin.
I looked into this and have made a patch which I have tested, and it does not cause the crash anymore. The interesting thing about this, is that my Block Chance test project already had the YEP_StatAllocation plugin in it, and enabled. I think I maybe had a modified version in there to prevent the crash, maybe?
At any rate, the problem is actually very similar to the one I was talking to Zelanius about earlier, regarding the extra parameters formula plugin as well - the YEP plugins all assume that there are only 10 xparams, and I coded block (blk) to be xparam(10), which is number 11. Because of this, the YEP plugins attempt to lookup values for that xparam, but return null, or undefined values, because they weren't defined the correct way, and crash. In this case, both of us could be considered to be at fault, YEP because they hardcoded their plugin to assume there would always be 10 xparams, despite having the ability to dynamically assign the same null values, and me because defining a new xparam maybe isn't great for compatibility.
Anyways, I uploaded the fix for this to the store page. Import it into the project. I put it at the bottom of the list, but it should work anywhere below the StatAllocation plugin.
If you want to be able to allocate points to block chance, however, that's not going to be something I can help you with.
Thank youRamza! And not at all. I was wanting to keep Block Chance attached to the shields and being able to allocate points to it would defeat the purpose. I appreciate your help!
Hi Ramza, in YEP's plugins, there are functions to add x- and s-params using additions. I just wanted to check if there is a similar function in Shield Block and Parry? Please advise.
The reason I am asking is because I am implementing a passive skill system, and using YEP's plugins, I can do like a actor.addTgr(x) to add to the param w/o creating states, as too many passive states on the battler can lag the system quite a bit in my experience (in fact, I scrapped my earlier project because I was over-reliant on states to implement my passives resulting in a super laggy game).
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.
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.
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. :)
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.
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!
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.
The block chance plugin isn't working for me, but the parry plugin is working. I have the status plugin that also shows that a character has a 0 block chance even though they have a shield with a 100% block chance tag.
The image shows the plugins and order I am currently using.
Block Chance should be loaded directly after YEP_BattleEngineCore. Move it in the list to be between that and dual wield.
Also, from the other comment, your shield does not have a note tag that gives it the block state. The plugin parameters specify a state ID to be the 'block state', if an actor is not afflicted with that state, their block chance is always zero.
Parry does not have that limitation, so it is working normally. Add a <passive state: x> to the shield, and set the ID for the block state in the plugin parameters to whatever you used for x.
Then make sure you paste the block state note tags into the state, because the state is where the actual blocking happens. The tag is in the plugin help documentation, or also there's a .txt file available for download that has the default one in it.
Without the state on the actor, a block can't happen, and if the actor has the state, but the state doesn't have that note tag on it, the block will "happen" but since the state note tags are what does everything, nothing will actually happen, no animation, no damage reduction, etc.
Again, parry works normally because it doesn't have a required state to work, and the note tags that would be on that state are in a notebox in the plugin parameters instead.
Thanks for the quick response; I think it is working now!
I got this plugin before I got passive states to work, and I don't think I read it carefully enough. The readme info doesn't seem to explicitly mention that the passive state plugin is needed. It says YEP BattleEngineCore & YEP BuffsStatesCore is needed right away.
Technically, it isn't needed per se, you just need to make it so that an actor that should be able to block has the block state on them. There are ways to do that without using passive states, but that is the most simple way to do it.
With the power of hindsight, and two more years of experience, there are definitely things I would do different, and in fact, have done differently with the MZ version of this plugin. Alas, porting those changes to the MV version is probably inadvisable due to the number of changes users would have to make to get it working again.
The default block effect, which is a custom react effect on the block state, and is included in the help documentation contains a line:
target.requestMotion('guard')
This line sets the target to doing a guard motion. I've noticed when using the yanfly CTB battle system, that while it does make this motion, it almost instantly returns to the idle stance right afterward. In the default battle system, the guard motion spends a full 15 frames (or more maybe?) before returning. There are gifs of both on the store page showing it happening in both systems.
If you want to show a different motion, or any motion at all, you can duplicate that line somewhere else in the react effect, or change 'guard' to the other motion types, the parry extension uses the attack motion of the equipped weapon, for example.
I'm uncertain, does this require Yanfly's Battle Engine Core? I'm interested in getting this, but I currently use another author's battle systems (like MOG's) and I'm wondering if everything would work fine (I use front view). I don't mind the shield effect not playing, just simply wondering about the mechanics itself.
Also, does the shield block have any functions that can be used for the Buff & States Core? Such as (target.result().shieldBlocked)? x : y, or something similar
The block plugin does not require YEP_BattleCore to work, but it does require YEP_BuffsStatesCore. It uses a function target.result().isBlocked() with BuffsStatesCore to activate the block effect from a react effect tag on the block state, meaning if you don't have BuffsStatesCore, while the actors' block rates and values can be seen and update, they won't do anything at all.
The plugin includes a sample txt file for a react effect note tag to get the desired block effect to happen. You can edit the react effect tag to add in other effects to a successful block as well. I had one in my old project where a successful block created a yanfly hp barrier equal to the damage that was mitigated, for example.
Hello, thanks for responding! You have me sold. Lots of cool things can be done with this - for both the defender and attacker, as well as opening up even more gameplay options. I'm excited to use this as well as combining it with the parry extension!
I've actually been following you for some time, but I forgot about the splendid scripts you make, cheers!
That is correct. The plugin is hard-coded to assume that the item in the second equipment slot is a shield.
While it is difficult to change this, as several parts of the plugin function by specifically checking the shield for things like animation and block percent, it's not impossible to make a patch for this. Unfortunately, if you have different characters with different equipment loadouts, like some actors have two weapons, and some don't have shield slots, a really basic patch probably wouldn't work.
I'd recommend setting actors who use two weapons to be dual wield type instead of manually giving them two weapon slots, though that is going to make it so that dual wielders can't wear shields at all, so might not exactly fit your needs either.
To my frustration, I seem to be having an issue where the game will not show damage numbers on a block, even if it's just a percentage block, and irregardless of whether or not I set hide pop-ups to true or false. Actor health still goes down, but no damage numbers show. I've been testing by having a 100% block rate 20% damage blocked shield in play and letting enemies hit for a while.
Edit: with some more troubleshooting I've got guard displaying after temporarily disabling the parry plugin. For some reason despite having a very obvious animation attached to it, parry was triggering with priority over a 100% block rate. I'm still puzzling out an odd interaction with Olivia's Battle Impact plugin where the Guard impact effect seems to butt heads with the Block animation and it seems to coin flip which plays--and if Guard impact plays, it won't display damage numbers. Hmm.
Parry chance is calculated before block, so if the attack is parried, it doesn't check against block, and since parrying is all or nothing, no damage popup is displayed.
As for the Olivia battle impact plugin, I can't tell why it would do that, you'd think it'd be either one way, or the other, but not randomly choose between the two. I don't have the plugin myself, however, so I can't look into this problem very well.
I love this plugin and it's got me pretty excited about designing elaborate shield-use mechanics in my current project. As a quick note, the demo project requires but does not include most of its plugin dependences (I presume this may be in part due to Yanfly shifting plugins in part behind pay requirements.) Figured I'd give you a heads up though--if all else fails you could have a 'packaged' demo so someone can try it out without having access to those additional plugins?
In the meantime, I noticed that you'd played around with a 'flat-footed' state, though I didn't see it used in the demo near as I could tell; I love the prospect though as it pertains to blocking--and also, potentially, parrying.
I was curious as to how you might suggest going about implementing such a state as a thought exercise--I figured it could be set to auto-resolve after an action is taken, to represent the actor being ready to receive attacks, but I'm a bit on the fence for implementation when it comes to how broadly to apply the state and when.
Presumably, via Yanfly passives or otherwise, the flat-footed state could auto apply to everyone and then fall off as actors perform actions; this could be trimmed down with a qualifier for only applying the state if a given actor -also- has the 'blocking' state, since a reduced block chance isn't relevant to actors who can't block in the first place. However, if a theoretical flat-footed state also applied to parry chance, that gets a bit broader.
Overall not necessarily too huge a deal in the context of 'actors are flat-footed when battle starts'--but it does open the door for more D&D-minded mechanics like sneak attack, etc. too--with actor abilities that can leave an actor 'flat-footed' for however long and dealing bonus damage or whatever other effects as a result. Just food for thought!
That is correct, I had to remove the yanfly plugin dependencies from the demo project as I'm not allowed to redistribute them. They are still loaded in the plugin manager, so someone wanting to use this plugin can simply drag and drop the correct yanfly dependencies into the plugin folder of the demo to quickly get it up and running.
I can think of one fairly easy way to implement the flatfooted state, and that's by using the <block chance: -x> tag on a state (or <lower block chance: x> but this tag is deprecated). You'd use that in combination with passive state conditions, or other conditions that always add it to the actors at the beginning of an enemy ambush, or whatever else you want, or even add the state to targets of specific skills.
You could also use that state as a trigger to change sections of action sequences as well.
← Return to Add-on
Comments
Log in with itch.io to leave a comment.
Good morning,
Is it possible to filter the states blocked by this plugin?
Let me explain. If an enemy attacks with an ability that poisons and my hero blocks, I would like the poison to be blocked as well. On the other hand, I use a lot of invisible state for the player to trigger various effects (like recovering MP after having suffered magic damage for example). These effects are therefore triggered by states associated with all enemy attacks. I want these states not to be blocked. Is it possible to select the states to be blocked and those which should not be?
Hello there.
That isn't currently possible, but it is a great suggestion, so I'll see about adding it in for a future update.
~Ramza
Thank you, that would be perfect
I have added that request in the latest version. I didn't do a lot of testing, but it doesn't seem to cause any crashes, and worked as intended in my test project. Give it a try and let me know if you have any issues.
~Ramza
It works perfectly for me.
A big thank you to you.
I'll let you know if there's a bug, but it looks fine to me right now.
Hey Ramza. Thanks again for the StatAllocation patch but for some strange reason, all of the Extra Parameters crash when allocating due to the patch. I'm assuming that might be because of Ex Parameter limit. I just wanted to give you a heads up. I may have to try to reach out to Yanfly for a fix in that regards. Thanks a bunch!
EDIT: There was a typo on line 5 of the patch, xparamsetallocationfix wasn't used on line 6, as it was a typo. I just replaced that and it worked right away
Hi Ramza,
I have another question on the Block Chance and Parry Chance plugin. Is there a way to make individual weapons or shields have the chance of parrying or blocking based on a user stat's, like level, for example?
The reason I am asking is because in my game, I have, let's call them legendary, equipment that I want to tie to the user's level, to prevent them from being too over-powered if the user obtains them early. The intention of these equips is that they will be more powerful than the most powerful buyable equipment in endgame, but they can be obtained early, and some as part of the plot.
Thanks in advance!
Edit: Nevermind, ignore me, I realized YEP has no function for this for their xparam and sparam plugin either, so I am forced to fix those values anyway.
Hey Ramza. I've been using your plugin for quite awhile now and never had any issues until recently. For some strange reason, any attacks against the player and viewing the Status window, trigger this error. I have all of the required Yanfly plugins. I turned off the Olivia's Set Bonuses plugin and it crashed with that as well. I have Block and DW (with menu extension) under BattleEngineCore, and exparamfix under AutoPassiveStates. I followed all of Yanfly's load order to make sure I had things in their correct place. I'm not quite sure what happened.
Block State is the same code as you have here, I changed plugin parameters to match my State ID, I copied the animations from your project just to make sure it wasn't that. So I'm not sure what's going on. Any help would be appreciated.
EDIT: I have discovered the cause is StatAllocation. Not sure how to get around that as that is a crucial plugin.
Hello there.
I looked into this and have made a patch which I have tested, and it does not cause the crash anymore. The interesting thing about this, is that my Block Chance test project already had the YEP_StatAllocation plugin in it, and enabled. I think I maybe had a modified version in there to prevent the crash, maybe?
At any rate, the problem is actually very similar to the one I was talking to Zelanius about earlier, regarding the extra parameters formula plugin as well - the YEP plugins all assume that there are only 10 xparams, and I coded block (blk) to be xparam(10), which is number 11. Because of this, the YEP plugins attempt to lookup values for that xparam, but return null, or undefined values, because they weren't defined the correct way, and crash. In this case, both of us could be considered to be at fault, YEP because they hardcoded their plugin to assume there would always be 10 xparams, despite having the ability to dynamically assign the same null values, and me because defining a new xparam maybe isn't great for compatibility.
Anyways, I uploaded the fix for this to the store page. Import it into the project. I put it at the bottom of the list, but it should work anywhere below the StatAllocation plugin.
If you want to be able to allocate points to block chance, however, that's not going to be something I can help you with.
~Ramza
Thank youRamza! And not at all. I was wanting to keep Block Chance attached to the shields and being able to allocate points to it would defeat the purpose. I appreciate your help!
Hi Ramza, in YEP's plugins, there are functions to add x- and s-params using additions. I just wanted to check if there is a similar function in Shield Block and Parry? Please advise.
The reason I am asking is because I am implementing a passive skill system, and using YEP's plugins, I can do like a actor.addTgr(x) to add to the param w/o creating states, as too many passive states on the battler can lag the system quite a bit in my experience (in fact, I scrapped my earlier project because I was over-reliant on states to implement my passives resulting in a super laggy game).
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
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.
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
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
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.
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!
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
The block chance plugin isn't working for me, but the parry plugin is working. I have the status plugin that also shows that a character has a 0 block chance even though they have a shield with a 100% block chance tag.
The image shows the plugins and order I am currently using.
Here is the block chance tag used.
Hello there.
Block Chance should be loaded directly after YEP_BattleEngineCore. Move it in the list to be between that and dual wield.
Also, from the other comment, your shield does not have a note tag that gives it the block state. The plugin parameters specify a state ID to be the 'block state', if an actor is not afflicted with that state, their block chance is always zero.
Parry does not have that limitation, so it is working normally. Add a <passive state: x> to the shield, and set the ID for the block state in the plugin parameters to whatever you used for x.
Then make sure you paste the block state note tags into the state, because the state is where the actual blocking happens. The tag is in the plugin help documentation, or also there's a .txt file available for download that has the default one in it.
Without the state on the actor, a block can't happen, and if the actor has the state, but the state doesn't have that note tag on it, the block will "happen" but since the state note tags are what does everything, nothing will actually happen, no animation, no damage reduction, etc.
Again, parry works normally because it doesn't have a required state to work, and the note tags that would be on that state are in a notebox in the plugin parameters instead.
Thanks for the quick response; I think it is working now!
I got this plugin before I got passive states to work, and I don't think I read it carefully enough. The readme info doesn't seem to explicitly mention that the passive state plugin is needed. It says YEP BattleEngineCore & YEP BuffsStatesCore is needed right away.
Technically, it isn't needed per se, you just need to make it so that an actor that should be able to block has the block state on them. There are ways to do that without using passive states, but that is the most simple way to do it.
With the power of hindsight, and two more years of experience, there are definitely things I would do different, and in fact, have done differently with the MZ version of this plugin. Alas, porting those changes to the MV version is probably inadvisable due to the number of changes users would have to make to get it working again.
~Ramza
That makes sense. I appreciate your work. Thanks for making something that so many games should have!
Is there a way to program when a block happens, it uses the characters/enemy guard motion?
Good day.
The default block effect, which is a custom react effect on the block state, and is included in the help documentation contains a line:
target.requestMotion('guard')This line sets the target to doing a guard motion. I've noticed when using the yanfly CTB battle system, that while it does make this motion, it almost instantly returns to the idle stance right afterward. In the default battle system, the guard motion spends a full 15 frames (or more maybe?) before returning. There are gifs of both on the store page showing it happening in both systems.
If you want to show a different motion, or any motion at all, you can duplicate that line somewhere else in the react effect, or change 'guard' to the other motion types, the parry extension uses the attack motion of the equipped weapon, for example.
~Ramza
thanks! and yes I saw the gifs so i was kinda confused, but the ctb is probably the issue.
I'm uncertain, does this require Yanfly's Battle Engine Core? I'm interested in getting this, but I currently use another author's battle systems (like MOG's) and I'm wondering if everything would work fine (I use front view). I don't mind the shield effect not playing, just simply wondering about the mechanics itself.
Also, does the shield block have any functions that can be used for the Buff & States Core? Such as (target.result().shieldBlocked)? x : y, or something similar
Hey there.
The block plugin does not require YEP_BattleCore to work, but it does require YEP_BuffsStatesCore. It uses a function target.result().isBlocked() with BuffsStatesCore to activate the block effect from a react effect tag on the block state, meaning if you don't have BuffsStatesCore, while the actors' block rates and values can be seen and update, they won't do anything at all.
The plugin includes a sample txt file for a react effect note tag to get the desired block effect to happen. You can edit the react effect tag to add in other effects to a successful block as well. I had one in my old project where a successful block created a yanfly hp barrier equal to the damage that was mitigated, for example.
Hello, thanks for responding! You have me sold. Lots of cool things can be done with this - for both the defender and attacker, as well as opening up even more gameplay options. I'm excited to use this as well as combining it with the parry extension!
I've actually been following you for some time, but I forgot about the splendid scripts you make, cheers!
It appears if using yep_equipcore, and using <equip slot> will break the blocking. For example:
<Equip Slot>
Weapon
Weapon
Shield
Head
Body
Accessory
</Equip Slot>
That is correct. The plugin is hard-coded to assume that the item in the second equipment slot is a shield.
While it is difficult to change this, as several parts of the plugin function by specifically checking the shield for things like animation and block percent, it's not impossible to make a patch for this. Unfortunately, if you have different characters with different equipment loadouts, like some actors have two weapons, and some don't have shield slots, a really basic patch probably wouldn't work.
I'd recommend setting actors who use two weapons to be dual wield type instead of manually giving them two weapon slots, though that is going to make it so that dual wielders can't wear shields at all, so might not exactly fit your needs either.
Yo, Ramza! Thanks for accommodating ALL of my requests! What a legend.
You're welcome. Keep doing what you do! :)
To my frustration, I seem to be having an issue where the game will not show damage numbers on a block, even if it's just a percentage block, and irregardless of whether or not I set hide pop-ups to true or false. Actor health still goes down, but no damage numbers show. I've been testing by having a 100% block rate 20% damage blocked shield in play and letting enemies hit for a while.
Edit: with some more troubleshooting I've got guard displaying after temporarily disabling the parry plugin. For some reason despite having a very obvious animation attached to it, parry was triggering with priority over a 100% block rate. I'm still puzzling out an odd interaction with Olivia's Battle Impact plugin where the Guard impact effect seems to butt heads with the Block animation and it seems to coin flip which plays--and if Guard impact plays, it won't display damage numbers. Hmm.
Parry chance is calculated before block, so if the attack is parried, it doesn't check against block, and since parrying is all or nothing, no damage popup is displayed.
As for the Olivia battle impact plugin, I can't tell why it would do that, you'd think it'd be either one way, or the other, but not randomly choose between the two. I don't have the plugin myself, however, so I can't look into this problem very well.
I love this plugin and it's got me pretty excited about designing elaborate shield-use mechanics in my current project. As a quick note, the demo project requires but does not include most of its plugin dependences (I presume this may be in part due to Yanfly shifting plugins in part behind pay requirements.) Figured I'd give you a heads up though--if all else fails you could have a 'packaged' demo so someone can try it out without having access to those additional plugins?
In the meantime, I noticed that you'd played around with a 'flat-footed' state, though I didn't see it used in the demo near as I could tell; I love the prospect though as it pertains to blocking--and also, potentially, parrying.
I was curious as to how you might suggest going about implementing such a state as a thought exercise--I figured it could be set to auto-resolve after an action is taken, to represent the actor being ready to receive attacks, but I'm a bit on the fence for implementation when it comes to how broadly to apply the state and when.
Presumably, via Yanfly passives or otherwise, the flat-footed state could auto apply to everyone and then fall off as actors perform actions; this could be trimmed down with a qualifier for only applying the state if a given actor -also- has the 'blocking' state, since a reduced block chance isn't relevant to actors who can't block in the first place. However, if a theoretical flat-footed state also applied to parry chance, that gets a bit broader.
Overall not necessarily too huge a deal in the context of 'actors are flat-footed when battle starts'--but it does open the door for more D&D-minded mechanics like sneak attack, etc. too--with actor abilities that can leave an actor 'flat-footed' for however long and dealing bonus damage or whatever other effects as a result. Just food for thought!
That is correct, I had to remove the yanfly plugin dependencies from the demo project as I'm not allowed to redistribute them. They are still loaded in the plugin manager, so someone wanting to use this plugin can simply drag and drop the correct yanfly dependencies into the plugin folder of the demo to quickly get it up and running.
I can think of one fairly easy way to implement the flatfooted state, and that's by using the <block chance: -x> tag on a state (or <lower block chance: x> but this tag is deprecated). You'd use that in combination with passive state conditions, or other conditions that always add it to the actors at the beginning of an enemy ambush, or whatever else you want, or even add the state to targets of specific skills.
You could also use that state as a trigger to change sections of action sequences as well.