Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
Morn Yvri Winters173 days ago (7 edits)

So i disabled Weapon Unleashed, now the weapons are not using <Replace Attack: X> as a command.

(also i made sure to get rid of the <skill_id:x> notetag from Weapon Skill, a default plugin that RPG Maker MV provides)

(UPDATE: I disabled the Weapon Skill Plugin and it still occurs)

It still performed a second attack, in addition, i found something strange in the console

(this is the second party member, they are currently wielding the "Mobster Full-Auto" and absolutely nothing else in their offhand, it still registered a second attack being executed)

(Here is the loadout thats being used, while this is in the "Troop Battle Test" System, i can confirm this still occurs outside of it)

Something else i would also like to clarify is that the dual wield weapons are using the same notetag, so its not interchanging notetags with one another, in fact, i had to acutally alter this a while ago and remove a couple of weapons because i couldn't get them to behave like RPG Maker 2003's Weapons nor could I locate a proper solution)
(To better describe this, basically i have two sets of skills, one that attack a single target, and the other that attacks multiple targets all at once, i had to remove dual wield weapons that struck all targets at once as i had realized dual wielding could only go so far, so now dual wield weapons are only one hit targets while things like shotguns stick to being all hit targets but two handed).
The Mobster Full-Auto is meant to be a two-handed weapon however.

(Also, another reason I am using weapon unleashed is so i can replace the "Defend" Command, which is also why ive got Weapon Skill to the side)
Reply
Ramza173 days ago

Okay, that is weird. 

So where the battle system is picking up that the actor is currently dual wielding, even when he isn't,  one of two things is happening:

  • The weapon isn't actually twohanded
    • Maybe something broke the notetag, or the function that turns the weapon twohanded?
  • The function that checks if the actor is currently dual wielding isn't properly detecting the actor as wielding a two handed weapon.

To test for the first thing, in battle, from the console, we can use almost the same script as before:

$gameParty.members()[1].equips()[0]._isTwoHanded

This will return true if the weapon in the main hand of the actor is tagged as two handed. 

If the script returns false:

  • The <twohanded> note tag on the weapon is not present, or is otherwise not being parsed, maybe it's inside of another tag by mistake, or has been typo'd
  • The note tag is being parsed, but it's being removed by something else, this would be the weirdest compatibility problem I'd have encountered, as something would need to be specifically removing that value from every item after my plugin loaded, which would almost be malicious.
  • The note tag exists, but you're using an older save file from before this plugin was installed to test, meaning the items in your savegame's database are from before this note tag was present to be parsed.

If the script returns true:

  • Something might be removing your weapon temporarily during the attack sequence. This could be a state, or an action sequence. If at some point during the skill use you don't have a weapon, the system considers dual wielding barehands as dual wielding, so it would call your actor dual wielding.
    • If that was the case though, it wouldn't consider you as currently dual wielding via the previous script call except for in the middle of the attack sequence, meaning it should show false on that above script check during the idle part of battle.
  • There is a problem with the logic in my function that determines if someone is dual wielding, that isn't taking into account a two handed weapon. That's be a major bug, and it'd be weird if no one had noticed it until now, but could be possible.

For transparency sake, I haven't tried to recreate this problem yet, as I had recently fully reinstalled windows and haven't set up my test environment yet. If the second option above is true, I should be able to easily reproduce the problem, though.

Anyways, put the above script into the console and see what it gives out, I'll get my test environment going here and start seeing if I can reproduce the problem.

~Ramza

Reply
Morn Yvri Winters172 days ago (1 edit)

So, i tested it out again, it came back as true.


Something else i should note is that during gameplay (where two-handed weapon removes offhand item, making it empty), it does behave as intended, HOWEVER, i am reminded of something, there was an instance where I've had the plugin act funny:

When i had first encountered the issue of the two-handed weapons attacking twice, i tried out my own solutions at first, that being i turned every character into a "Normal Slot-Type" character until they equipped a "Dual Wield" Weapon, where in which they'd become "Dual Wield Slot-Types" from a trait inside the respective weapon.


So i had it set it so "dual wielding" would be activated by equipping one weapon (basically I set it so the slot-type would change upon equipping said weapon) yet for whatever reason, when i had done so, the game did something really weird during combat, where my character was attacking with dual wielded seperate attacks (as intended), but after the first attack, it immediately auto corrected to a "Normal"-Slot Type character (MID-Battle, not like... after battle but MID BATTLE), any weapon with the dual wield slot type trait did not switch my character back to dual wielding, just kept  it in "Weapon; Attachment" rather than going to "Weapon; Weapon".

Additionally, when this oddity occurred, it did the "double" attack. One normal, one blank.

Reply
Ramza172 days ago

Okay, well that thing is unrelated to the other thing. That's actually a known issue with how dual wield attacks work in the system.

During the act of attacking, each weapon is unequipped for the attack of the other hand. That means if the only source of the dual wield trait on the actor is one of his weapons, when it is removed, he's no longer dual wielding. That causes all kinds of wonky behavior, and that's why you want the trait on either the actor, or his class, or a permanent state (from the yep passive states plugin).

Good news, I fixed the problem. The issue was from the new parameter in 2.74, equip only mode, which most people wouldn't be using. I'd messed up a check for if that parameter was enabled, which was causing the isCurrentlyDualWielding() function to return true without doing any checks to see if the actor was actually dual wielding.

The idea behind this check was that if out of battle, OR if the plugin parameter was enabled, it would only ever return the actual slotType of the actor (for which 0 is normal and 1 is dual wield type). This was to maintain compatibility with in combat plugins that also relied on knowing if the actor was dual wield type or not, like the YEP equip change in battle plugin.

But since I'd accidentally reversed this check, if the parameter was disabled, it would trigger that check, which was returning if the actor was dual wield type, and not if he was actively dual wielding, as expected. Which leads to your problem, where a two handed weapon was considered dual wielding. It likely also had the same problem with actors using a shield in their offhand, although I didn't test for that.

I have uploaded v2.75 which corrected this bug. Everything should work fine now. Thanks for the report, and sorry it took me a while to find the culprit, as I said, I didn't have my test environment running on my new windows install, so I was honestly trying to avoid doing that as much as I could by asking many questions from you about your specific use case.

~Ramza

Reply
Morn Yvri Winters172 days ago

The fix is a success, thank you very much! and you are completely fine!

Reply
AboutFAQBlogContact us
Copyright © 2025 itch corp · Directory · Terms · Privacy · Cookies