RMMV Ramza's Plugin Suite Support topic MEGATHREAD

[ramza]

What version of the dual wield plugin are you using? This was something that definitely happened a long time ago, but this was resolved in version 2.40.
When a mainhand swing happens, any traits on offhand weapon are ignored, and when an offhand swing happens, all traits on the mainhand are ignored.
To test this, make a new skill, and tag it as <offhand skill>, then make a weapon that has a trait set to add attack state 'poison'. Set the skill to use <Add State: Normal Attack 100%>
Put that weapon in the main hand, and any other weapon in the offhand, and then do a battle test and use the skill. It will not apply poison to the target with that skill.
I have tested this in my own test project, with a main hand that does poison, and an offhand that does blind, and tested the normal attack, a mainhand skill that hits twice, and an offhand skill that hits twice.
In the case of a normal attack, both states are applied, which is expected, because each weapon is used once, each hit was successful. If one of the individual attacks missed, the state on that weapon was not applied. For the other two skills, the <mainhand skill> did not apply blind, and the <offhand skill> did not apply poison, as expected.

 

[DavePerry]

Dual wield version 2.69a
BlockChance version 2.26

When I get back home I'll try what you suggested

 

[DavePerry]

I tried what you suggested but when I used that new skill with <Offhand Skill> only my offhand attacked anyway.
I made a couple videos showing whats going on for me only using the few plugins in a new game. This is just regular attack.. It works perfectly when BlockChance is OFF.

Plugins:


BlockChance is OFF: Works Great.




BlockChance is ON: Mainhand misses and my offhand applies both states.

 

[ramza]

Alright, you are correct. That is a problem, I have reproduced it in my test project.

The fix is to load Block Chance in the correct load order.

Block Chance loads directly after BattleCore, Dual Wield loads after the other YEP Battle plugins, especially DamageCore if you have that.

I reproduced the problem in my test project (which already had block chance in it) by moving block chance below dual wield in the load order.


Move Block Chance to load directly after BattleCore, and put dual wield somewhere below it.

I did not realize that loading them out of order would cause this problem specifically, but it is likely that it would've caused other issues, specifically with the menu extension.

 

[DavePerry]

strange I thought I already tried moving blockchance order as well.. Alright thank you Ramza.

 

[DavePerry]

Thanks again for the help Ramza. Also, I had a quick question about the compatibility between ALOE_YEP_MenuControlParameter and your DW_MenuExtension Plugin. Is there a way to get these to work together? If not no biggie I guess but it would be nice if possible. The MenuControlParameter plugin allows you to set any parameter / xParameter to be displayed on the equip screen etc but I can't seem to get it to work nicely to show Block Chance with your plugin as well. I might not be able to use the show Block Chance but if that's the case so be it.

 

[ramza]

Using that plugin you could set user.blk to be displayed as if it were any other xparam. It won't replace the offhand attack value as it would with the menu extension, but it should work just as well for your purposes.

 

[DavePerry]

Hey Ramza, I added the parry chance plugin and it's working great but I'm wondering if I could somehow set a parry animation for weapons / players and not just enemies? Kind of like what you did for the block chance plugin? Maybe that line of code for the parry effect that plays animations for enemies could be changed to affect enemies and players? Is there an easy way to go about this? thanks ; )

 

[ramza]

The plugin parameter that contains the parry react effect is user customizable.

if (target.result().isParried()) {
    if (!target.isActor()){
        target.startAnimation(target.enemy()._parryAnimation)
        value = 0
    } else {
        var se = {
        name: "Hammer",
        volume: 90,
        pitch: 100,
        pan: 0
        };
        var MWPType = Ramza.ParryParams.MWPType
        if (MWPType == "Individual"){
            var slot = target.result().slot
            var mainhand = (target.equips()[0]) ? target.equips()[0] : null
            if (slot == 1){
                target.changeEquip(0, null)
            }
            AudioManager.playSe(se)
            target.performAttack()
            value = 0
            target.changeEquip(0, mainhand)
        } else if (MWType == "Offhand"){
            var mainhand = (target.equips()[0]) ? target.equips()[0] : null
            target.changeEquip(0, null)
            AudioManager.playSe(se)
            target.performAttack()
            value = 0
            target.changeEquip(0, mainhand)
        } else {
            AudioManager.playSe(se)
            target.performAttack()
            value = 0
        }
    }
}

In that codeblock you could replace the AudioManager.playSe(se) function with one to show an animation instead. While it doesn't have note tags for a custom animation to set on weapons, you could use the built in function of the note box to parse your own note tags and plugin them in here in a similar way to what I did with the enemy note tag.

Tag a weapon with anything you want in the note box, and you can call it back via script with $dataWeapons[1].meta.whateveryoutaggedit

For example, if I tagged a weapon with <PARRYANIMATION:4> $dataWeapons[1].meta.PARRYANIMATION will be "4". So you could do that, and then put a target.StartAnimation(mainhand.meta.PARRYANIMATION) into the react box above, and it'd show that animation.

Personally I feel like the action of the actor swinging his weapon at the incoming attack, and making a sound effect is sufficient, but if you want something more, the codeblock is fully editable.

If you mess something up in there and it doesn't work anymore, you can re-import the plugin and it should revert to default, too. Just in case.

 

[DavePerry]

Thanks a bunch I'll mess around with that.

 

[DavePerry]

Is anyone else having issues with the 'weapon attack formulas' plugin? It seems to work fine if my weapon damage is just a flat value like say 100 but if I put a.atk * 2 on my weapon it returns 0 damage when calculated with the skill. Not sure how to make this work with notetags.
~~~~~~~~~~~~~~~~~~~~~~~
sword:
<Weapon Formula>
a.atk * 2
</Weapon Formula>

skill formula box:
this.weaponFormula() * 5

Returns 0 damage
~~~~~~~~~~~~~~~~~~~~~~~
sword:
<Weapon Formula>
100
</Weapon Formula>

skill formula box:
this.weaponFormula() * 5

Returns 500 damage
~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[ramza]

Is anyone else having issues with the 'weapon attack formulas' plugin? It seems to work fine if my weapon damage is just a flat value like say 100 but if I put a.atk * 2 on my weapon it returns 0 damage when calculated with the skill. Not sure how to make this work with notetags.
~~~~~~~~~~~~~~~~~~~~~~~
sword:
<Weapon Formula>
a.atk * 2
</Weapon Formula>

skill formula box:
this.weaponFormula() * 5

Returns 0 damage
~~~~~~~~~~~~~~~~~~~~~~~
sword:
<Weapon Formula>
100
</Weapon Formula>

skill formula box:
this.weaponFormula() * 5

Returns 500 damage
~~~~~~~~~~~~~~~~~~~~~~~~~~

Good day.
I looked into this problem and it appears to be a bug. I will fix it in an update, as I already know what the issue is, but in the mean time, you can wrap the entire function into an eval() function to make it work correctly.

eval(this.weaponFormula()) * 5

It appears that it could handle flat numbers fine but it wasn't actually evaluating anything the function returned if it wasn't a number. I also identified another issue where damage splitting while dual wielding doesn't quite work with that either, so when I figure out how to fix that I'll release an update.

 

[DavePerry]

Sweet, thank you Ramza. ; )

 

[ramza]

Sweet, thank you Ramza. ; )

Alright, well, it looks like I can't really fix that problem, at least not super easily.
If I evaluate the weapon formula in the function itself, to return a number instead of the string, we run into the problem that a formula that references the target (ie: anything containing b.whatever) will cause a crash.
I could change it so that you have to provide the target when you call the function, so like this.weaponFormula(altformula, b), but that makes you have to edit the damage formula already, so I might as well leave it as is and just write in the documentation to wrap it in an EVAL like I said above.
I corrected the dual wield thing I was talking about above too, basically the weaponFormula (when it was working) was using the incorrect value for attack if the skill being used was a main, or off, or dualwield skill, causing it to do a lot more damage than expected.

I have uploaded version 1.12 to the page, redownload it from your library or the store page to update it.

Thanks for the report.

 

[zelanius]

@ramza recently, I found an odd error with the Shield Block in RMMV. It seems to be causing an error in the damage calculations. I am not sure why, but as soon as I equip the shield onto my characters, this happens. It doesn't throw an error as RMMV resolves any damage error by simply doing no damage (not even a message popup). I played around with disabling the plugins I have, and it appears that there is a plugin incompatibility with another plugin I use, namely ICF-Soft Param Core. I am not sure why (ICF-Soft Param Core does not override xparam 10, and it has it's own set of "pparams" if I need to create any new ones). Will keep testing to see if changing plugin order works.

EDIT: OK, there was definitely something with my order (I did not put Block Chance directly below the Battle Core, but under all the other YEP Battle Core extensions). However, for some reason Block Chance is not happening even when I set it to 100%, so not sure why (even Parry Chance seems wonky), but otherwise, everything is working as intended now, and I can live with it for now (kind of).

EDIT2: For some weird reason, as soon as I put the Block Chance to something lower than 100, the damage issue happen again (and only Block Chance, Parry Chance does not appear to interfere with the damage). In any case, even at 100% the blocking does not occur. My game is playable now as it is, however, so I will leave it as it is first.

 

[ramza]

@ramza recently, I found an odd error with the Shield Block in RMMV. It seems to be causing an error in the damage calculations. I am not sure why, but as soon as I equip the shield onto my characters, this happens. It doesn't throw an error as RMMV resolves any damage error by simply doing no damage (not even a message popup). I played around with disabling the plugins I have, and it appears that there is a plugin incompatibility with another plugin I use, namely ICF-Soft Param Core. I am not sure why (ICF-Soft Param Core does not override xparam 10, and it has it's own set of "pparams" if I need to create any new ones). Will keep testing to see if changing plugin order works.

EDIT: OK, there was definitely something with my order (I did not put Block Chance directly below the Battle Core, but under all the other YEP Battle Core extensions). However, for some reason Block Chance is not happening even when I set it to 100%, so not sure why (even Parry Chance seems wonky), but otherwise, everything is working as intended now, and I can live with it for now (kind of).

EDIT2: For some weird reason, as soon as I put the Block Chance to something lower than 100, the damage issue happen again (and only Block Chance, Parry Chance does not appear to interfere with the damage). In any case, even at 100% the blocking does not occur. My game is playable now as it is, however, so I will leave it as it is first.

The issues here seem weird, so I'd definitely lean towards it being some kind of compatibility problem with that ICF-Soft Param Core plugin, since I've never used it before, so I have no guarantee of any kind of compatibility with it.

I'd be interested to see the react effect tag on your block state as well. The actual damage reduction from blocking happens in that react effect, not during the action result, so if it ended up reducing the incoming damage by a weird value that wasn't a number, it'd end up causing the damage to also not be a number, and return 0 every time instead.

Also, if you could check in the console what actor.blk returns, it would greatly help in tracking down where the problem is. $gameParty.leader().blk should work. Set your block to 100 and it should return a 1 in the console. Set it to something lower and see what it returns.

Keep in mind also that tag for setting block rate (the chance to block) is <Block Chance: x> where x is a whole number. There is another tag with a similar name which is for setting the amount of damage reduction from an incoming attack when it is blocked - <Block Percent: x> reduces incoming damage on a successful block by x%. The default parameters for this plugin make all shields have a block percent set to 100%, meaning a successful block always reduces incoming damage by 100%, but you may have changed that to make it more like a different system.

The react effect seems like the likely cause of the issue right now at least, so let me see what you have in there and we'll go from there. The Parry Chance plugin actually doesn't use a react effect on a state at all, and has it's own thing in the plugin parameters that provides basically the same function, so it working and blocking not is a pretty good indicator of what's going on, I think.

 

[zelanius]

The issues here seem weird, so I'd definitely lean towards it being some kind of compatibility problem with that ICF-Soft Param Core plugin, since I've never used it before, so I have no guarantee of any kind of compatibility with it.

I am pretty sure that's the reason. I believe it has to do with the xparam too as ICF-Soft allows customization of the xparams, but only xparam0-9. However, since that is the new one I added to a recent project vs my previous practices, I believe this is the cause.

I'd be interested to see the react effect tag on your block state as well. The actual damage reduction from blocking happens in that react effect, not during the action result, so if it ended up reducing the incoming damage by a weird value that wasn't a number, it'd end up causing the damage to also not be a number, and return 0 every time instead.

Also, if you could check in the console what actor.blk returns, it would greatly help in tracking down where the problem is. $gameParty.leader().blk should work. Set your block to 100 and it should return a 1 in the console. Set it to something lower and see what it returns.

Keep in mind also that tag for setting block rate (the chance to block) is <Block Chance: x> where x is a whole number. There is another tag with a similar name which is for setting the amount of damage reduction from an incoming attack when it is blocked - <Block Percent: x> reduces incoming damage on a successful block by x%. The default parameters for this plugin make all shields have a block percent set to 100%, meaning a successful block always reduces incoming damage by 100%, but you may have changed that to make it more like a different system.

The react effect seems like the likely cause of the issue right now at least, so let me see what you have in there and we'll go from there. The Parry Chance plugin actually doesn't use a react effect on a state at all, and has it's own thing in the plugin parameters that provides basically the same function, so it working and blocking not is a pretty good indicator of what's going on, I think.

I followed the notetags according, so I set <Block Chance: 5> when I wanted 5% chance to block. As for the console, it returns "Uncaught SyntaxError: Unexpected identifier" regardless of the Block Chance. I did try to put Block Chance and Block Percent both at 100, but that doesn't work, and I know that Block is not happening because of a lack of the blocking animation.

I did a few more test, including with 100% Parry Chance, and it is not happening unless I turn off ICF-Soft's plugin, so it is definitely a conflict (not sure if Parry Chance takes up xparam?). However, strangely, despite switching off ICF-Soft, the error with Block Chance still occurs (just the blocking not happening - damage popup, etc. are fine), and the ICODE returns the same error instead of 1. I tried turning off all the non-YEP and non-Ramza plugins, but still same issue, so perhaps compatibility with ICF-Soft's plugin is not the only problem (maybe the order?).

I have attached a zip file with the excel showing the list of active plugins in my game and the order they are in.

 

[ramza]

@zelanius I downloaded the latest versions of the ICF main utility, as well as the params plugin, and imported them into my block chance demo project running the latest block chance version.

With the main utility near the top of the plugin list, block chance directly below BattleCore, and ICFSoft_ParamsCore at the very bottom of the list, I am able to load into the project without errors, although the console seems to output the entire contents of the top six plugin parameters. I was then able to use the console to check for the actor's block chance without error, $gameParty.members()[1].blk and got the expect console output (0.7).

I have attached the plugin list for the demo so you can see the order I have the plugins in. You have many more than this, so that's going to be a bit more complicated.

I don't see anything in the softparams plugin that actually interferes with how I defined block chance as an xparam, so I don't think that'd be causing any issue, and the fact that I can load both without having that error points me away from it being a compatibility issue at this point.

Please show a screenshot of that unexpected identifier error you were getting, preferably with the entire error stack if there is one.

 

[zelanius]

@ramza seems like I was calling the code incorrectly. Now I can call Block Chance using the console and it shows up with the right number. The damage calculations are also running correctly. However, the block chance is simply not happening, even with 100 in everything.

Below are the notetags I used, with Passive State 230 being the stat I assigned for blocking (and I copied over the notetags for the state too):
<BLOCK CHANCE: 100>
<BLOCK PERCENT: 100>
<BLOCK VALUE: 100>
<Passive State: 230>

The problem I have is that there is no error stack at all, simply that block isn't happening, and even with the new order, parry also isn't happening. Only when I turn off ICF-Soft does parry happen, but not block. Not sure how else to check for the error though. Is there a code I can use in the console to check, like the state reaction or damage calculations?

 

[ramza]

@zelanius
If the function in the ICODE above gave back a 1 in the console, that means that the chance to block is 100%, which is should be given the tags you just showed there.

That means the problem is one of two things:

• The block state isn't triggering it's react effect
• The block state triggers, but it doesn't do anything

To test if the block state is being triggered at all, simply edit the react effect tag on the block state to include a console.log('did this work?') at the top, before any if checks or anything else. If you don't see that in the console after the attempted block, we know the issue is that the react effect is never happening.

For reference, the help documentation includes an example of what react effect note tag should be on your state. I asked you to share yours earlier but maybe you missed it.

<Custom React Effect>
console.log('did this work?')
var blockValue = (target.isEnemy() ? target.enemy().blockValue : target.equips()[1].blockValue)
var blockPercent = (target.isEnemy() ? target.enemy().blockPercent : target.equips()[1].blockPercent)
if (target.result().isBlocked()) {
    value -= Math.round(value * (blockPercent/100));
    value -= blockValue
    value = Math.max(value, 0)
    var blockAnim = (target.isEnemy() ? target.enemy().blockAnimation : target.equips()[1].blockAnimation)
      target.startAnimation(blockAnim, true, 0);
      target.requestMotion('guard')
}
</Custom React Effect>
<Custom Deselect Effect>
setTimeout(function () {
 target.requestMotion('walk')
}, 180);
</Custom Deselect Effect>

Basically, take that, put it on your block state, and see if it works.

Now, if this doesn't show anything in the console, the problem is that the react effect isn't triggered at all. One reason why this could be is because the attack you're trying to block cannot be blocked. The default parameters make all physical skills blockable, but if you disabled this parameter, you need to tag them specifically with <blockable> for them to even have the chance to be blocked. if the skill you're being hit with isn't physical, it can't be blocked unless it has that tag either.

Also, if the defending actor has a state that prevents movement (like stun, or sleep), they will likewise be unable to block.