MV - Dual Wield

Greetings.

I'm sorry you're having this issue. But I am unable to reproduce the problem on my end, so it might be being caused by a bug with some configuration you're using.

• Please ensure that you are starting a fresh savegame when you're testing this, as the equipment in an old saves database files may not contain all of the metadata that the plugin is expecting.
• Did you use the <Forbidden Wtypes: x y z> note tag on any weapons that are currently equipped, or might show up in the equipment list?
  • If yes, can you temporarily remove that tag and test to see if the crash still happens?
• How is dual wielding set on an actor? Is it on their class traits? Their actor traits? A piece of equipment? A weapon?
• Does the crash happen when trying to equip a weapon in the main hand or offhand slot? Both?
• Does the actor start with two weapons already equipped? Does the crash still happen if they have only one, or no weapons at all equipped?
•  If you make your actors no longer dual wielding type (remove the trait), does the crash still happen?

Once I get a little more info, we'll try to get this sorted out for you.

~Ramza

There is currently no way to do that exactly.

The modifier plugin parameters for dual wielding, offhand, and two handing a weapon can all be eval'd. By default, they're just a float number (0.75 for example), but you can use code in this box to make the number different based on a condition being met using a ternary operator: 

(user.isStateAffected(21) ? 0.90 : 0.75

Something like the above would make the offhand do 90% normal damage if the user is affected by state 21, or 75% or not. These can be nested as well, allowing for different levels of offhand mastery, or ambidexterity, or whatever

(user.isStateAffected(21) ? 0.90 : (user.isStateAffected(26)) ? 0.80 : 0.75

I'm not entirely sure that's the exact code you'd use to do that, I didn't get a chance to test it, but I had set it up once a long time ago, in an old project, and it was designed for that use case. It's not exactly what you're looking for, but it can work for what you need.

The hit and crit bonuses are weapon specific. Any source of hit rate or crit rate that isn't on a weapon is given to both hands, and any that is on a weapon is only given to that one weapon. There is no way to change this currently.

~Ramza

I believe that is because when the character doesn't have anything in their offhand, the menu considers them only wielding one weapon, so it doesn't show the possible change of the atk value of the offhand weapon.

Unfortunately, I don't have a good way to fix this, as the VS plugins are all obfuscated, and I don't have a way to hook into and change their menu scenes. It's frankly surprising that there was any change at all on that one.

Does it evaluate the proper way on the equip scene?

~Ramza

Hello there.

I've never tested it with that plugin before. It doesn't do much to modify equip slots, only making it so the second weapon slot can also hold shields, so I don't think there'd be any issues. You might have to change around the load order and see if it works better one way or the other, though.

Of course, if there is any compatibility problems, you can always post about them and I can take a look to try to fix them, too.

~Ramza

Hey there.

This appears to be an issue with a change I implemented a while back. Originally I had modified the actor.isDualWield() function to return false in battle if the actor was dual wield type, but wasn't currently wielding two weapons. A couple of updates ago, I undid this change, and replaced most of those checks with a new function actor.isCurrentlyDualWielding(), the purpose of this change was so that in battle equipment changing plugins didn't incorrectly determine that an actor couldn't wield an offhand weapon.

It appears after I made this change, the function causing your crash was not updated. With the original change to the dual wield function, it would not have checked the wtype of the offhand item if the actor was barehanded or using a shield, but now it does both. 

I have uploaded a fix for this, in the newest version. The second issue you posted about below is also because of the same thing, the function that determines if an actor is dual wielding, and adds the second attack action was also checking if they were dual wield type, and not if they were currently dual wielding.

~Ramza

UPDATE: Managed to solve this by changing the 'includes' calls in isMHAllowedWithOffHandWtypeId and isOHAllowedWithMainHandWtypeId to 'contains' calls.

I figured it out, I in fact did not download the correct battle core plugin. Ignore my previous comment!

Hey there.

That is a weird thing going on there. Does it also happen to the hit % stat if you do the same thing to it?

I'll try to confirm if this is just a visual problem or if the stats are actually reverting too. I'm thinking its just a weird window refresh problem, but not 100% sure just now.

~Ramza

Greetings.

I have uploaded new versions of the menu extension and the dual wield plugin that corrects this issue. 

In the case where the actor is using two exactly identical weapons, and the dev is not using independent weapons from ItemCore, there is now a special case where a temporary object is created in $dataWeapons, which is used as a placeholder for one of the weapons when these checks are being made. After the calculations are done, the fake weapon is replaced with the original, and then it is removed from the database. This corrects the display issue on the menu scene, as well as the same issue in battle during split attacks, which you didn't report, but was caused by the same root cause as the display problem.

Check them out and let me know that everything is working for you.

You know, I don't think you can actually do that.

I'd never considered the possibility that someone would want to prevent equipping a shield with certain offhand weapons, and even the tags that prevent a weapon from being equipped with specific other wtypes doesn't include locking out shields for that wtype. 

I thought just now that maybe you could workaround this by disallowing the shield armor via the traits box on the claw weapons, but it turns out you can only allow equipment from that box, not disallow it.

I'll have to add this function in the next update.

~Ramza

Hello there.

Turns out, that is a quirk with how I added the extra attack. It might actually even be a bug, now that I think about it. The extra dual wielding attack is just given to the actor as if he had Attacks+1 on him, but is not calculated in the same way, so giving him another attacks+1 trait does not give him a third hit. 

I think this is just a logic problem on my part. I accomplished this by changing the function where it returns the number of attacks+ the actor has, to return either 1 or their attacks+ number, instead of 0 or their attacks+ number. Meaning if the two numbers are both one, it will still only do one extra attack.

Line 891 in the latest version of the dual wield plugin is where this happens:

return Math.max(this.traitsSumAll(Game_BattlerBase.TRAIT_ATTACK_TIMES), 1)

if you change that line to read the following, it will fix the problem:

return Math.max(this.traitsSumAll(Game_BattlerBase.TRAIT_ATTACK_TIMES)+ 1, 1);

-Ramza

Hey there.

While I haven't personally tried it for such a purpose I can say that it is very unlikely to work for this purpose. The only way it functions is if the actor is set as dual wielding, which only gives you two weapon slots by default, meaning you'd need to have used a plugin like EquipCore to get extra weapon slots on top of those two, or you'd need to have had another plugin modify the dual wield equip type to give extra weapon slots.

In either case, this plugin expects only a maximum of two weapons, so it would only ever strike twice, and each hit would ignore the stats of only one of the multiple weapons being wielded, the others would be treated as armor, most likely. 

Even if you had someone modify it so that it attacked once for each weapon, instead of hardcoding to twice if dual wielding, there'd still be many other functions and effects that would need to be tweaked to make it work. 

I'm not saying it isn't possible to modify it to make it work like that, but it's not something it will do out of the box.

~Ramza

Greetings.

I haven't tested this plugin with baseparamcontrol, but I don't think that's the issue here, or not exactly, anyway.

What is the actual damage formula of the skill being used? This plugin automatically replaces a.atk (or user.atk) with a special calculation depending on which hand is being used. I suspect that calculation isn't taking the baseparamcontrol into consideration, because like I said, I haven't exactly tested with it. If your damage calculation is something like (a.atk - b.def) -a.mat it could end up returning a weird value that ends up being zero somehow, and results in only your mat being used.

Hey there.

The menu extension is needed for Parry and expertise to be shown on the menu, if it's not there (or it's crashed before the project loads, causing it to not load at all) the YEP menu will not know how to interpret the requested parameters and draw a blank line instead.

Check the console for any errors, sometimes a crash on load just causes the plugin to abort loading instead of straight crashing the project.

Also, please share the crash message (and console stuff) from when it crashes with YEP_ExtraParamFormula as well. I've a couple of crashes from that thing over a long time, and I suspect I know what it is, but I need the errors to troubleshoot.

MHCalc() and OHCalc() should work for this. Make sure to include the brackets, as it is a function that returns the value, not the value itself.

I'm not sure how that plugin gets its values, but those functions are on all Game_Actor objects, so that should be what you need.

Hi there.

Someone asked this question before, and my experimenting with a workaround to make it work for them actually led to me incorrectly thinking I had a weird bug in a newer version.

There is no way to prevent the second attack in the case that an enemy dies after the first one, not within this plugin, anyway. The way the attack times + trait is programmed is that it just repeats the target action section multiple times, as if it were all part of the same sequence. It doesn't do a check in between. My plugin simply hooks into this, and swaps weapon stats around (and images) when the second attack is made. 

What you can do is make your attack sequence check to see if the target is dead first, and not do anything in the target section at all. This will cause the second attack to not happen if the first killed the target, but it has another issue in that action sequences that already contain and if check will not work, as they can't be nested. You could get around this with a different plugin (like this one by SergeofBIBEK).

If you're not using Yanfly's action sequences plugins at all, you'll need those in order to make this change first.

If you're already using an action sequence, simply wrap the target action in a check to see if the target is dead, and if it is, do nothing:

before:

<target action>
motion attack: user
wait: 12
attack animation: target
wait: 3
action effect: target
wait for animation
</target action>

after:

<target action>
if (target.hp > 0)
    motion attack: user
    wait: 12
    attack animation: target
    wait: 3
    action effect: target
    wait for animation
end
</target action>

Like I said above, if your sequence already has an if check in it, nesting them doesn't work, but you can fix that with the plugin I linked.

-Ramza

Hi there.

I haven't tested that plugin specifically, but here's what I can gleam by looking at it:

• It should be mechanically compatible. Stat points spent in ATK will apply correctly to both main and offhand attack values.
  • It might be possible that ATK added from this might not be multiplied by the offhand or two-handed multipliers, I think it should work, but, like I said, I haven't tested it. The multiplier is added after other effects that modify the base param, so it should apply after this plugin.
• The scene showing the stat purchasing should only show base params, and by looking at the video for this plugin, it doesn't appear to be reusing one of the scenes I directly modified, so it should continue to do this, and will not show the split params in this window. 
• As above, because this window doesn't show the split params at all, there should be no issue with a blank slot, or Block Chance showing up on this scene either, if you're using that plugin as well.

In conclusion, it should work, but it hasn't been tested. There's no reason why it shouldn't work, and any incompatibilities would be minor, and pretty easy for me to fix if someone were to report any.

-Ramza

Hello there.

I admit that I hadn't really considered such a bundle, or even a sale for the end of the pandemic. Technically, the sale I ran from April to the beginning of May was the biggest discount I had ever done, and the description definitely included some "Stay inside, make games instead" sort of language, and I don't want to have multiple sales really close together, particularly for similar reasons, because that can lead to consumer confusion, and sometimes people refunding bundles or individual plugins to buy the newest bundle as it's a slightly better deal, maybe.

Speaking of confusion, one main reason why I can't see myself doing a collaborative bundle with Irina or Olivia is that many of their plugins aren't strictly compatible with my own, and the majority of the others haven't been tested. If we somehow came together and made a giant collaborative bundle, it'd come with the caveat that several of the plugins included in it may  (nay, most likely will) not be compatible with each other, and I feel like that is going to lead to large influx of people who didn't read, or didn't know, making support posts in all of our channels asking for support that we will not be able to give. And since it's particularly difficult to held hold of Irina and Olivia, and I don't think either of them do much in the way of plugin support, a lot of those posts are going to fall to me, and I simply won't be able to help. 

In the end, that's probably going to lead to some refunds, realistically, and that isn't helping anyone involved. Customers get a bad taste in their mouth, the three of us get harassed, and everyone pays for it. Not to mention the possible fall-out, if word gets around that someone got a refund on the whole bundle because it wasn't compatible and they felt ripped off, maybe more people who bought the bundle get refunds too? It's a slam dunk, and then a bunch of people have some plugins they didn't even pay money for.

The other reason for not doing something like this is a bit more simple. I don't have any way to communicate with Irina or Olivia. Both of them make it very difficult to talk to them, especially about plugins. DMs on discord are blocked, and I don't share any servers in common with them that allow me to talk to either of them. If there is some sort of secret discord server that the disciples of Yanfly communicate on, I am not privy to it, unfortunately. Both of them have comments on their individual plugins turned off, and no community forum here. And both of them seem to ignore DMs and posts on the RPGMakerWeb website in their plugin support topics. With no special way for me, as a creator, to get in contact with either of them, there's no way for me to approach them and set up a deal like this in the first place. I might be open to such a deal if one of them approached me about it, but we'd have to iron out how the obvious incompatibilities of our plugins will be handled.

That being said, I appreciate the thought you put into your request, and I don't mind that it's asked publicly. For reference though, I can be reached on Discord via DM (Ramza#3215), I have a support topic linked on my profile here on the RPGMakerWeb forums as well, although that topic is kind of dead, necroposting it is alright., and I also respond to DMs on that site as well, which you don't need a certain number of posts or like to send.

Hey there.

The only plugin from that system that I know it works with is the weapon swap plugin, and only if you download the included patch. Even then, it doesn't work very well at all, especially in the menus.

Olivia disabled dual wielding in that plugin (probably in the other octopack plugins as well), either because in a true octopath-based battle system, there would be no dual wielding, or because there was some kind of issue with dual wielding she couldn't fix.

In either case, as I only own a copy of the weapon swapping plugin, it is the only one I have made a patch for. Since it appears from that plugin alone that Olivia didn't want dual wielding in the octopack, it's likely it's been disabled in one or all of the other plugins as well, and probably causes even more issues with them if you were to use my patch.

I toyed with this earlier, and it's possible via a conditional branch in your action sequence for the attack skill.

Because the target action part of the sequence is repeated for each attack, if you wrap the whole thing in an if check that checks the targets HP, you can effectively not do the second (or any subsequent) swings if the target has 0 HP.

When I was investigating a bug report a few weeks ago, I'd forgotten I'd set this up on my action sequence in my test project, and thought my update had broken the offhand attack, but it turned out my first hit was strong enough to kill the target.

if (target.hp > 0)
motion attack: user
wait: 12
action animation: target
action effect: target
wait for animation
else
death break
end

Hello there.

I can see that the plugin you linked is supposed to be compatible with Yanfly's Battle Engine plugin, but I am unsure just how far that compatibility goes. I don't have a leTBS project set up to test from at the present, and it will not be a quick task for me to do so, as I don't personally use that plugin myself.

Since I'm not sure how much of BattleEngineCore actually makes it into use in leTBS, I'm not real sure where the incompatibility actually is. It could be as simple as the Attack Times+ trait not functioning in leTBS, or it could be as complex as action sequences not being implemented at all. Or both. 

To start, could you describe what does or doesn't happen when testing in your own project? Does a second attack occur for dual wielding actors at all, just with the wrong damage/animation/weapon, or does only one attack happen? If only one attack happens, does it show both the battle animations for each weapon on top of each other, or just one animation? Does it simply crash and not work at all?

I expect the menu stuff should probably still be working fine, except unless leTBS has some sort of in battle status menu, in which case it would need to be patched to work with the offhand weapon slot properly.

I can't guarantee I'll be able to patch it to make it compatible, but I can give it a shot.

-Ramza

Hello again.

I apologize for how long it took me to get back to you on this one. Unfortunately, after digging into the LeTBS plugin a bit, I can only conclude that I don't know enough about how this plugin works to get it working together with dual wield. 

I tried to find the part of the plugin where it processes the attack action specifically, as a starting point for how to make this compatible, but the plugin is massive, and has little documentation. Blindly poking around inside did not prove to be very effective. If support for Attack Times + as a trait were to be built into leTBS, I feel like dual wield would probably work almost 100% with just that change, but since I can't personally figure out where the attack sequence is even processed, let alone what to change to make it duplicate certain parts of it, I will be unable to do this myself.

There are also some unforeseen compatibility issues to do with the lack of working action sequences in leTBS. My plugin relies on secretly adding commands to the action sequences to reset some attack data between skill uses, which is why YEP_BattleEngineCore is a hard requirement. While leTBS supports BattleEngineCore, it does not seem to make use of action sequences at all, which means any compatibility patch between my plugin and leTBS will need to find a new way to reset this attack data.

As it is right now, you can use dual wield and the extensions with this plugin, but they do not split damage, or effects, or hit multiple times. You can still use this to make dual wield actors capable of wielding shields in their offhands, make weapons that can only be wielded in the main or off hands, or two-handed, and make shields that can be wielded with two-handed weapons. As is, the only thing I could suggest to try to get the core features of this plugin to work are to contact someone who has a lot more experience working on the leTBS plugin.

Sorry.

That's a decent suggestion, but it doesn't account for shields tagged <Offhand>. These shields can be equipped even when an actor has a two-handed weapon equipped, so there is always the possibility of equipping something in that slot, even when a two-handed weapon is being used.

Of course, one could say that for a project where shields aren't a thing, or where light shields don't exist this is a good suggestion. I'd like to keep this plugin as cookie-cutter as possible, though, so I don't think I can roll this into the main plugin.

However, for your own personal use, I'd look into the below function from YEP_EquipCore. The function is used to draw the 'empty' slots on the equip scene, and you can add in whatever functionality you need from here.

Window_EquipSlot.prototype.drawEmptySlot = function(wx, wy, ww) {
    this.changePaintOpacity(false);
    var ibw = Window_Base._iconWidth + 4;
    this.resetTextColor();
    this.drawIcon(Yanfly.Icon.EmptyEquip, wx + 2, wy + 2);
    var text = Yanfly.Param.EquipEmptyText;
    this.drawText(text, wx + ibw, wy, ww - ibw);
};

Add in an if condition, and check this._actor.icanMonkeyGrip() or alternatively a (this._actor.equips()[0] && !this._actor.equips()[0]._isTwoHanded) and that should handle what you're looking for.

Might come out a little something like this:

Window_EquipSlot.prototype.drawEmptySlot = function(wx, wy, ww) {
    this.changePaintOpacity(false);
    var ibw = Window_Base._iconWidth + 4;
    this.resetTextColor();
    if (!this._actor.canMonkeyGrip()){
        this.drawIcon(Yanfly.Icon.EmptyEquip, wx + 2, wy + 2);
        var text = "Locked";
        this.drawText(text, wx + ibw, wy, ww - ibw);
    } else {
        this.drawIcon(Yanfly.Icon.EmptyEquip, wx + 2, wy + 2);
        var text = Yanfly.Param.EquipEmptyText;
        this.drawText(text, wx + ibw, wy, ww - ibw);
    }
};

Just paste that code into a blank js file and import it into your plugin manager anywhere below YEP_EquipCore and that should do it.

-Ramza

Greetings.

Thanks for the report. This issue is caused because I had hardcoded the value to draw the offhand attack text/dark rectangle to offset from the first one by 30 pixels. The standard padding is 32, if I'm not mistaken, and to make room on the default resolution screen, I shrunk it by 2 pixels, and injected the offhand line using the extra space that afforded.

I can push an update that un-hardcodes this value, allowing you to specify it in cases like yours, where you've changed the default line spacing to make up for a resolution change and/or larger font choice.

Alternatively, you can manually make this change. Between lines 1205-1257 there are several calls which reference a 'y+30'. If you change that 30 to something slightly larger, it will shift the line down a bit. Fiddle with that number until you get equal spacing between the Off Strength line and the Toughness line below it and you should be good to go.

Edit:

Turns out, I had a few minutes, and since I'd already went to the trouble of finding out which lines to change, I went ahead and fixed it in v1.34. I have just uploaded the updated menu extension plugin, you can download it here.

The boxes for the dual wield modifiers (two-hand, offhand, dual wield damage %) are javascript evals.

This means you can use a ternary operator to make the value one of two values depending on a conditions.

if you put the following in your offhand modifier parameter box, it will increase the offhand damage to 90% if the actor has a state, or if the actor doesn't have the state, 75%.

(this.isStateAffected(X)) ? 0.9 : 0.75

because of the way the plugin uses this formula (this) is the actor. In the above statement, if the actor is affected by state X, his offhand modifier is 90%, but if he isn't, it's the base 75%.

You can also nest these, if you have multiple states that change the penalty (or grant bonuses)

(this.isStateAffected(X)) ? 0.9 : (this.isStateEffected(Y)) ? 0.99 : 0.75

It doesn't have to be a state either, anything on the actor object can be used, such as his name:

(this.actor().name == 'Harold') ? 1.12 : 0.75

Hope this helps.

I have corrected this in the latest revision B. It is available at the same download location.

Apologies for all the problems with this, like I said, I didn't get much of a chance to actually QA test it before I put it up.

Greetings.

I didn't previously have a way to do this, but I just rolled it into the menu extension addon. Someone had asked a question earlier about the names of the slots, and it made me think that he was asking for this feature, so I'd started looking into ways to do it. But then it turned out I misunderstood what he was asking for, so it wasn't needed anymore.

If you also have the monkey grip plugin, you'll need to update it to the newly released version 1.01 to support the slot name changes I made in v1.33 just now. Let me know if there are any issues with it, I didn't get much of a chance to thoroughly QA test it myself, beyond making sure it displays correctly, and doesn't cause a crash (of which, there were several).

-Ramza

The menu extension plugin contains parameters for you to set what the main and offhand slots are called. The default is just 'Main' and 'Off'. Using longer names like 'Right-hand' make the status scene look a bit squished, but on wider resolutions that would look fine too.

Unless I'm misunderstanding you, and you're actually looking for a way to dynamically name that slot... Like some actors it says 'right' and others it says 'primary'. That's something I can definitely do if you're looking for it.

This is the first I've heard of that problem, but given how much of a pain it was to implement that feature, it wouldn't surprise me at all to learn there's still a bug or two with it.

I'm at work for the next several hours, but when I get home I'll be able to take a closer look. If you could verify if the normal attacks are actually using the stats of the locked weapon, by slapping wildly unrealistic ATK values on them, that'll save me a few minutes in tracking down the issue though. If not, no big deal, I'll have a look when I can.

This looks like the same issue Miah1377 reported after updating from an older version.

That function being referenced as the cause of the crash is trying to read a property that is assumed to be present on all weapons as of v2.62. I just released a sort of patch that stops it from causing the crash error, but the cause of the problem is that it appears that you are testing using a save file that was made prior to upgrading the plugin to version 2.62. The way the database for items is loaded is weird, and because this plugin wasn't reading notetags for locked wtypes prior to v2.62, the property that it saves onto weapons isn't present on your items database for the save file. The plugin (prior to 2.65) assumed that the property is always present, so it goes right to reading from it, which causes the crash error you posted when it finds the property as undefined.

As I said, v2.65, which was just uploaded a few hours ago will stop the crash (or it should anyway), but the actual fix is to start a new save-game file from which to test further.

Greetings.

Sorry for the problem here, but the error code you posted is just what I needed to track this down. The problem here is that I believe you are using an old save to test your project, before you installed the new version of this plugin. That function causing the error is checking an array that should be present on all weapons as of the 2.62 update - specifically, even weapons that do not prevent the use of other wtypes will still have this value, it's simply blank, so it doesn't cause this error.

The simplest way to prevent this error is to start a new save-game in your project to test. I have just uploaded version 2.65, which will also correct this issue (causing crashes isn't good, even if the reason isn't exactly the plugin's fault).

I'm not 100% sure, as I don't use that plugin myself, but I believe Weapon Unleash is coded in such a way as that all other plugins think the new skill is the attack skill, so it should properly do atk calculation. 

Keep in mind, though, that dual wielding unleashed weapons does not work correctly. The offhand weapon's unleash skill is ignored, so the mainhand skill is used twice. This is because the Weapon Unleash plugin doesn't include dual wielding support at all.

At which point are you noticing delay? For dual wield actors, and only when using a dual wield skill (one tagged as dual wield) this plugin does copy sections of the target action and replays them, but only if you've got it set up to do that. If you're not using it in that way, it shouldn't cause any delay to the actual action sequence, and even in the above example, it shouldn't cause any noticeable effect.

Hello there.

It would appear that this is an uncaught bug caused in v2.55, when I added some checks to lock main or offhand weapons on actors who were using skills that required a specific weapon type. It looks like after this update I was also checking for locked weapon types on enemies, who don't use weapons, and therefore throw this error.

I have uploaded a fix, and apologize for the inconvenience. The reason why it worked in my demo project was because the uploaded demo project is using an older version of the plugin. Redownloading the plugin file from the download page will show it updated to v2.58 with this fix included.

Thanks for reporting this issue.

I'm not familiar with that plugin. However, the 'disable state' option in my plugin 's parameters can be used for exactly the scenario you describe. Try putting it as a passive on the arrow weapons and see how it works out.

I'm honestly not sure how it will work out with the arrows being weapons, though, so you might need a more creative workaround. Technically, you could make them shields and they'd still fit in the offhand, and their base parameters would be added to the single attack of the main hand weapon in that case. They'd need to be etypeId 2 specifically for that to work without modifying my plugin, though. You'd probably need some special equipment requirements to prevent a player from equipping arrows as a shield without a bow, or something as well.