-
You've discovered RedGuides 📕 an EverQuest multi-boxing community 🛡️🧙🗡️. We want you to play several EQ characters at once, come join us and say hello! 👋 -
IS THIS SITE UGLY? Change the look. To dismiss this notice, click the X ---> -
There is a suspension/ban wave happening, we're still gathering information. Please keep regular discussion to Suspension MegaThread and please consider submitting a Suspension report to RG.
Plugin - MQ2Melee (1 Viewer)
- Thread starter Redbot
- Start date
think i rather do a condition to see if its on than turn it off completely
Have had issues recently with my berserkers Cry Havoc. MQ2Melee used to manage the ability and pop it whenever it was down in the song window. Now, it is triggering once about every 6 seconds while in combat. Anyone else having this issue and/or does anyone know a fix? Also, my MQ2Melee is havoc=0, and the ability still triggers.
ok - despite the pile of other issues that mq2melee has - I know *why* its doing that its doing, i just don't know if it is an mq2 bug or not.
I spoke to mule back on Jan 20th about this exact concern and he said it didn't appear to be an issue - that perhaps it was broken before and is fixed now.
The DurationWindow for Cryhavoc is reporting 0 --- which is supposed to be the "long" duration window - and 1 is supposed to be the "short" duration song window
Cry Carnage shows up in the short duration window.
I will get in touch with mule again and give him this example so we can determine if this is incorrect.
if it was broken and is now fixed, I can update mq2melee with the fix no problem - but as you can see it shows up in the short duration and reports back a 0 - so /shrug
I spoke to mule back on Jan 20th about this exact concern and he said it didn't appear to be an issue - that perhaps it was broken before and is fixed now.
The DurationWindow for Cryhavoc is reporting 0 --- which is supposed to be the "long" duration window - and 1 is supposed to be the "short" duration song window
Cry Carnage shows up in the short duration window.
I will get in touch with mule again and give him this example so we can determine if this is incorrect.
if it was broken and is now fixed, I can update mq2melee with the fix no problem - but as you can see it shows up in the short duration and reports back a 0 - so /shrug
I manually play my warrior so yes it will turn it off completely.
I am having an issue where I believe this plug in is mashing Mangling Disc for my Berserker when ever its up. I dont want to stop using MQ2melee because the stick features and they keeping my buffs up is great but I pretty much never want it to mash that disc again. Even when raiding I rarely use this disc unless everything is timed out perfect and I wont miss a burn cycle. The 22min timer on Disconcerting from using this is way too much of a dps loss. Im new to the site and have been trying to figur ehtis out for a couple of days but I cant seem to get anything to stop it without unloading melee. Any help for me?
I am getting ability spam on my WAR and BER with the WAR abilities Commanding Voice and Paragon Champion. On Berserker he spams Cry Cranage. Im pretty sure its coming from mq2melee with my limited knowledge and through research Ive found it could be holy/down related or fixable? Could anyone help get me on the right path for a solution?
yeah this is an issue with mq2main atm that eqmule is looking into.
I posted above with a few things that are causing the issues
you would want to disable those in mq2melee and then create a holy/down to fire instead
on your warrior:
INI:
/melee commanding=0
/melee fieldarm=0
/melee saveon your zerk
INI:
/melee cryhavoc=0
/melee save
Good day Redguides, and gents @ChatWithThisName @Knightly @Sic
Synopsis
The knights (Pal & Shd) bash with 2H appears broken in MQ2Melee (not bashing!).
Code review suggests update needed in respect of the change to AA from patch in November 2019.
My read it is a one liner change of text that defines the AA to look for. ( Former, "Two-Handed Bash" to current "Improved Bash")
Accepting bash does work if explicit in macros or other plugins, but MQ2Melee is coded to do it, so suggests fix is required.
Background
I use KissAssist and also the delegation to MQ2Melee. ( UseMQ2Melee=1 in the [melee] section )
In fights, combat actions from KA profile are working great, and generally the primitive abilities from Melee do as well, e.g. disarm.
But I noticed the knight is not bashing, with a 2H equipped. ( He will do, if bash is in the DPS section of KA. )
A warrior will do bashing, sword and shield, and not defined in KA, MQ2Melee is doing it.
EQ Patch reference
We know the AAs of knights were changed in 2019 and to quote from our own forums here (Nov 20th 2019).
MQ2Melee source review
Last year, Knightly was kind enough to talk through getting the VV & MQ2 source from git repo and how to build this.
I have pulled again today the MQ2Melee and see it has not changed in some time.
In this I can see some work has been done with bashing, but not with regards the patch, and you gents have been maintaining this.
Thankfully, there arent too many lines of code that set the boolean for HaveBash.
From this I see the hard coded check for old names of the knights 2 hander bashing AA, and no references to the new name. Improved Bash
I infer, line 3452 needs GetAAIndexByName("Two-Handed Bash") updated to GetAAIndexByName("Improved Bash")
The actual bash action in the MQ2Melee code:-
Explains why it works with classes using a shield.
Explains why it fails for 2H as the "HaveBash" isnt boolean being set, as the AA name has changed, so the second half wont ever be a true condition until code updated, and so no call to the bash ability is made.
From EQ Live
Regards and Best Wishes
Synopsis
The knights (Pal & Shd) bash with 2H appears broken in MQ2Melee (not bashing!).
Code review suggests update needed in respect of the change to AA from patch in November 2019.
My read it is a one liner change of text that defines the AA to look for. ( Former, "Two-Handed Bash" to current "Improved Bash")
Accepting bash does work if explicit in macros or other plugins, but MQ2Melee is coded to do it, so suggests fix is required.
Background
I use KissAssist and also the delegation to MQ2Melee. ( UseMQ2Melee=1 in the [melee] section )
In fights, combat actions from KA profile are working great, and generally the primitive abilities from Melee do as well, e.g. disarm.
But I noticed the knight is not bashing, with a 2H equipped. ( He will do, if bash is in the DPS section of KA. )
A warrior will do bashing, sword and shield, and not defined in KA, MQ2Melee is doing it.
EQ Patch reference
We know the AAs of knights were changed in 2019 and to quote from our own forums here (Nov 20th 2019).
MQ2Melee source review
Last year, Knightly was kind enough to talk through getting the VV & MQ2 source from git repo and how to build this.
I have pulled again today the MQ2Melee and see it has not changed in some time.
MQ2Melee change control:
// | 2019-02-07: Fixed Two Handed Bash skills... + saar zerker tbl disc...
// | 2019-11-14: Updated by Sic/CWTN Yaulp to default to "off"
// | 2019-12-29: Updated by ChatWithThisname-> Added Warrior, Berserker, Rogue discs for ToV. Rearranged information by class instead of alphabetically.
// | 2020-01-06: Updated by Sic - Added Paladin, Shadowknight, Ranger, Monk, Necro, and Beastlord ToV discs/spells
//In this I can see some work has been done with bashing, but not with regards the patch, and you gents have been maintaining this.
Thankfully, there arent too many lines of code that set the boolean for HaveBash.
MQ2Melee Sub Configure line 3451 to 3455:
#if !defined(ROF2EMU) && !defined(UFEMU)
HaveBash = GetAAIndexByName("Two-Handed Bash") ? true : false;
#else
HaveBash = GetAAIndexByName("2 Hand Bash") ? true : false;
#endifFrom this I see the hard coded check for old names of the knights 2 hander bashing AA, and no references to the new name. Improved Bash
I infer, line 3452 needs GetAAIndexByName("Two-Handed Bash") updated to GetAAIndexByName("Improved Bash")
The actual bash action in the MQ2Melee code:-
MQ2Melee Sub BashPress line 3423:
if (ShieldType(ContSecondary()) || (got2hand && HaveBash)) idBASH.Press();Explains why it works with classes using a shield.
Explains why it fails for 2H as the "HaveBash" isnt boolean being set, as the AA name has changed, so the second half wont ever be a true condition until code updated, and so no call to the bash ability is made.
From EQ Live
Regards and Best Wishes
Redbot updated MQ2Melee with a new update entry:
BigDorf bashes bugs
Read the rest of this update entry...
BigDorf bashes bugs
Read the rest of this update entry...
Hello all!
Have you seen:
I am trying to figure out where this is coming from, and thought would ask others if they have seen this too.
It appears to be combat related, and so far I have seen it with primary and secondary slot items.
The shield flicker, as if picked up from inventory and dropped quickly, has happened when I have two shields "no trade" (but not lore obviously!), one normally equipped the other sitting in inventory having looted from mobs or received from quest.
The attunable spam, I have an attuned weapon equipped, but the same item is looted and is "tradeable" in bags, yet seems to be trying to equip it!
They are being driven by KissAssist.
The characters in question have no bandolier defined at all, and I am not intentionally using them. I havent configured anything for weapon swapping.
This appears to be a combat related activity, as only seems to happen fighting mobs and not whilst medding, buffing or navigating.
My gut hunch, is something is trying to make sure "item" is equipped in combat, and is finding "same name" item in bags and trying to euip it - without seeing the slot already has "item" in place.
i.e. its looking, seeing in bag, picks it up, tries to equip it. This makes it appear on cursor, and in "no trade" it goes straight to bags or swapped over with the already equipped. The "attunable" is trying to equip it and so the pop-up question box is presented, several times during combat.
I intend to carry out some tests to investigate this, but thought would ask you all for your experiences.
Regards and Best Wishes
Have you seen:
- items on cursor flicker in combat, e.g. your shield?
- attunale spam, several windows asking to attune same item?
I am trying to figure out where this is coming from, and thought would ask others if they have seen this too.
It appears to be combat related, and so far I have seen it with primary and secondary slot items.
The shield flicker, as if picked up from inventory and dropped quickly, has happened when I have two shields "no trade" (but not lore obviously!), one normally equipped the other sitting in inventory having looted from mobs or received from quest.
The attunable spam, I have an attuned weapon equipped, but the same item is looted and is "tradeable" in bags, yet seems to be trying to equip it!
They are being driven by KissAssist.
The characters in question have no bandolier defined at all, and I am not intentionally using them. I havent configured anything for weapon swapping.
This appears to be a combat related activity, as only seems to happen fighting mobs and not whilst medding, buffing or navigating.
My gut hunch, is something is trying to make sure "item" is equipped in combat, and is finding "same name" item in bags and trying to euip it - without seeing the slot already has "item" in place.
i.e. its looking, seeing in bag, picks it up, tries to equip it. This makes it appear on cursor, and in "no trade" it goes straight to bags or swapped over with the already equipped. The "attunable" is trying to equip it and so the pop-up question box is presented, several times during combat.
I intend to carry out some tests to investigate this, but thought would ask you all for your experiences.
Regards and Best Wishes
@Ladon had a similar experience a while back > HERE < he said unloading mq2exchange fixed it - are you using mq2exchange for something?
Thanks for your quick thoughts @Sic
I havent used "exchange" that i know of, but i do see it is flagged to load in the MQ ini.
mq2exchange=1
Unless macro or other plugins are giving exchange instructions, i havent got anything in mind that is requesting gear changes.
The items in use are same as when loaded the characters, and started doing stuff in exp zones.
With regards pulls, i dont believe so either.
The warrior i had seen shield flicker on, ( PullWith=Throw Stone ). The attunable feature, that was on a cleric ( PullWith=Melee ), but cleric is not pulling role, is standing at camp and joining in as assist only.
My gut feel:-
... but so limited on test samples, is why i thought to ask others what they have seen.
Test strategy in mind
Test server
I havent really used the EQ test servers much, playing on live normally.
Is it possible to quickly have characters set on Test server, and give them items to use ( e.g. duplicate defiant items, or other non-lore weapons & shields ) ?
If the answer is yes, can someone please give pointers on how this is done please. e.g. what commands or steps required.
Thanks.
I havent used "exchange" that i know of, but i do see it is flagged to load in the MQ ini.
mq2exchange=1
Unless macro or other plugins are giving exchange instructions, i havent got anything in mind that is requesting gear changes.
The items in use are same as when loaded the characters, and started doing stuff in exp zones.
With regards pulls, i dont believe so either.
The warrior i had seen shield flicker on, ( PullWith=Throw Stone ). The attunable feature, that was on a cleric ( PullWith=Melee ), but cleric is not pulling role, is standing at camp and joining in as assist only.
My gut feel:-
- this has nothing to do with KissAssist ( I see you moved the original post to KA section of forum ).
- It is likely plugins, in particular MQ2Melee is coming to mind.
KA melee:
[Melee]
AssistAt=95
MeleeOn=1
FaceMobOn=1
MeleeDistance=75
StickHow=snaproll
AutoFireOn=0
UseMQ2Melee=1
TargetSwitchingOn=0... but so limited on test samples, is why i thought to ask others what they have seen.
Test strategy in mind
- setup a character with duplicate gear items, weapons and / or shield.
- if necessary, unload many plugins; save the nav movement and melee etc.
- use a basic hunting macro ( target mob, nav to, attack - rinse repeat ), that delegates to mq2melee for combat.
- go play whack a mob, and see what happens on screen.
- If seeing it with minimal plugins, and basic macro then ill further drive it manual. i,.e. run up to mobs myself and hit attack.
Test server
I havent really used the EQ test servers much, playing on live normally.
Is it possible to quickly have characters set on Test server, and give them items to use ( e.g. duplicate defiant items, or other non-lore weapons & shields ) ?
If the answer is yes, can someone please give pointers on how this is done please. e.g. what commands or steps required.
Thanks.
Being patch day and the servers down decided to read code. 
@Sic @Knightly if you gents agree with this thought, can this post move house again please, away from KissAssist to somehwere else, perhaps MQ2Melee?
Keeping in mind, characters are playing melee whack-a-mob
Reading source code I think this logics in MQ2Melee could be causes.
My read, save details of primary & secondary gear if something there already, do swaps if necessary, do bash, then equip items saved by their IDs.
Doesnt consider if item need to switch back, just looks to put back item id it saw and saved to ensure it is there.
So what does the Equip procedure do?
Oh no! Oh no!
That looks like the culprits to me.
A few things feel wrong here in the ordering of thinking.
BashPress has called to Equip, to ensure the original "item" is equipped and it hasnt necessarily changed. Calling always, and not just when it knows a change has happened.
Equip is assuming that there is a change required, without checking that first. Looking in bags for items of required ID, and not checking if already equipped.
I am thinking an early test inserted at 2309, to check for already equip, and not the style of check at 2322 either!
pseudo logic of the ilk; get the item id currently in SlotID, compare that to ID. If same, return false, as the item is already equip.
if they are not same, then can consider swap of items is required, and proceed as per line 2315 to hunt the bags for it.
That 2322, is assuming if it finds an item in bags then it needs equipping, without checking if same item id is already equipped.
If have two "no trade" shields of same name, that would explain the flicker.
if have an attuned and attunable weapon of same name, that would explain the attune spam.
( where i say name to the player observer, in code we know as item id ).
Last thing to mention, as do a quick grep of the source.
There are 9 uses of Equip in the code, after the prototype and procedure codes.
2 of those 9 are in that BashPress.
I think Equip needs the early test as mentioned above, to give quick wins ( return false ), if items already in place.
The other areas of code perhaps a review to see if can decide not to call Equip at all.
Regards and Best Wishes
@Sic @Knightly if you gents agree with this thought, can this post move house again please, away from KissAssist to somehwere else, perhaps MQ2Melee?
Keeping in mind, characters are playing melee whack-a-mob
Reading source code I think this logics in MQ2Melee could be causes.
My read, save details of primary & secondary gear if something there already, do swaps if necessary, do bash, then equip items saved by their IDs.
Doesnt consider if item need to switch back, just looks to put back item id it saw and saved to ensure it is there.
So what does the Equip procedure do?
Oh no! Oh no!
That looks like the culprits to me.
A few things feel wrong here in the ordering of thinking.
BashPress has called to Equip, to ensure the original "item" is equipped and it hasnt necessarily changed. Calling always, and not just when it knows a change has happened.
Equip is assuming that there is a change required, without checking that first. Looking in bags for items of required ID, and not checking if already equipped.
I am thinking an early test inserted at 2309, to check for already equip, and not the style of check at 2322 either!
pseudo logic of the ilk; get the item id currently in SlotID, compare that to ID. If same, return false, as the item is already equip.
if they are not same, then can consider swap of items is required, and proceed as per line 2315 to hunt the bags for it.
That 2322, is assuming if it finds an item in bags then it needs equipping, without checking if same item id is already equipped.
If have two "no trade" shields of same name, that would explain the flicker.
if have an attuned and attunable weapon of same name, that would explain the attune spam.
( where i say name to the player observer, in code we know as item id ).
Last thing to mention, as do a quick grep of the source.
There are 9 uses of Equip in the code, after the prototype and procedure codes.
2 of those 9 are in that BashPress.
I think Equip needs the early test as mentioned above, to give quick wins ( return false ), if items already in place.
The other areas of code perhaps a review to see if can decide not to call Equip at all.
Regards and Best Wishes
Worth unloading mq2melee and having your usemq2melee=0 in your kiss ini to check. Many folks would recommend getting rid of mq2melee usage with kiss these days anyhow - but sounds like a very strong suspect.
When we find an item we find the very first thing that matches it, just like how some things can break other things - like use item for bard epic can bug out if you have the ornament, and instead u have to force using it by item I'd since the ornament and item have diff ID'S, in the case of the same ID, it would just grab the first one.
When we find an item we find the very first thing that matches it, just like how some things can break other things - like use item for bard epic can bug out if you have the ornament, and instead u have to force using it by item I'd since the ornament and item have diff ID'S, in the case of the same ID, it would just grab the first one.
You know, I feel validated that four years later somebody finally encountered the same issue. There was a period of time (let's say four years) where I thought that I was crazy and had borked my settings file beyond repair. Reading my linked thread was sorta funny because my skills have improved since then.
KA loads and does a check for MQ2Exchange so that it can swap in items (ranged, pet focus, top-level inventory slot for pet items, etc) and MQ2Melee does have the functions that you linked to swap in a shield if you need to bash. There are a couple of situations that trigger the Attune popup to appear if you are running KA, Exchange, and Melee with Bash on but it's exacerbated by an INI that uses bandolier switching.
If you loot a non-lore attunable item when you have an *attuned* version in your inventory then neither plugin knows which, specifically, it needs to grab to swap in. If the unattuned version ends up in a higher-level bag slot then Melee will attempt to grab that one (because the name matches!) and equip it.
I've been able to replicate this with all three loaded on my SK but luckily most current-era primary/secondary gear is lore anyways.
I've started transitioning all of my characters away from using Melee simply because PullWith=Melee in KA12 causes your character to nav directly on top of the spawn after engaging, no matter if you UseMQ2Melee=0,1,2. I hate it.
KA loads and does a check for MQ2Exchange so that it can swap in items (ranged, pet focus, top-level inventory slot for pet items, etc) and MQ2Melee does have the functions that you linked to swap in a shield if you need to bash. There are a couple of situations that trigger the Attune popup to appear if you are running KA, Exchange, and Melee with Bash on but it's exacerbated by an INI that uses bandolier switching.
If you loot a non-lore attunable item when you have an *attuned* version in your inventory then neither plugin knows which, specifically, it needs to grab to swap in. If the unattuned version ends up in a higher-level bag slot then Melee will attempt to grab that one (because the name matches!) and equip it.
I've been able to replicate this with all three loaded on my SK but luckily most current-era primary/secondary gear is lore anyways.
I've started transitioning all of my characters away from using Melee simply because PullWith=Melee in KA12 causes your character to nav directly on top of the spawn after engaging, no matter if you UseMQ2Melee=0,1,2. I hate it.
thank you for your kinds words with regards this fix for knights bashing with 2 handers!
I have received an email today that pointed out, Warriors have an AA at level 105 for bashing with 2H.
It is called, "Two-Handed Bash". I have a test warrior loaded, and indeed there it is.
Sorry warriors! fixing knights broke yours!
EDIT: This has been coded, and pushed to git for merge when approved.
It will now be looking for either of the two AA, "Improved Bash" or "Two-Handed Bash", to decide if the character can bash with a two handed weapon.
I have received an email today that pointed out, Warriors have an AA at level 105 for bashing with 2H.
It is called, "Two-Handed Bash". I have a test warrior loaded, and indeed there it is.
Sorry warriors! fixing knights broke yours!
EDIT: This has been coded, and pushed to git for merge when approved.
It will now be looking for either of the two AA, "Improved Bash" or "Two-Handed Bash", to decide if the character can bash with a two handed weapon.
Last edited:
The good news of today, comes in two pieces.
With the test server up, I have ran around with a warrior using a vendor bought shield.
Actually, I bought two of the same shields, put one in secondary slot and the other sat in inventory.
#1
No macros running - so no KissAssist.
I manually ran out and played whack-a-mob, in which I started the attack and MQ2Melee took over.
The shield flicker on screen was there, and I saw the shield in inventory jump slots.
Re-tested, by placing the shield in a different slot and again it jumped to the first available inventory.
As gut hunched, KissAssist is not the cause, or troublemaker here.
#2
I had speculated on some code that would let me see what item I have, and what was being asked to do in Equip procedure.
With these, I threw some MQ2 window writes into the Equip procedure, rebuilt MQ2Melee and tested.
That worked, in the sense it reported that what is already equipped is what is being requested to change, and watched the same cursor and inventory behaviours.
Amended the code again, rather than just report it to MQ2 window, but now return clean ( true ) from the Equip procedure if the "ask" and "in place" are of the same item ID, before any searching in bags or swaps of items get done.
This next test run, my MQ2 Window comments are there (for debug evaluation only, so I know its this new build), and that cursor flicker, the inventory changes have stopped.
The second shield remained in position, in a lower down inventory slot and did not move as it had done prior to code change.
Happy days!
This should also reduce that chance of the "attune" feature as well. i.e. if already have "item" equipped and attuned, it wont try to use one from the inventory of the same name, as the Equip will return before it gets the chance to.
Regards and Best Wishes
With the test server up, I have ran around with a warrior using a vendor bought shield.
Actually, I bought two of the same shields, put one in secondary slot and the other sat in inventory.
#1
No macros running - so no KissAssist.
I manually ran out and played whack-a-mob, in which I started the attack and MQ2Melee took over.
The shield flicker on screen was there, and I saw the shield in inventory jump slots.
Re-tested, by placing the shield in a different slot and again it jumped to the first available inventory.
As gut hunched, KissAssist is not the cause, or troublemaker here.
#2
I had speculated on some code that would let me see what item I have, and what was being asked to do in Equip procedure.
With these, I threw some MQ2 window writes into the Equip procedure, rebuilt MQ2Melee and tested.
That worked, in the sense it reported that what is already equipped is what is being requested to change, and watched the same cursor and inventory behaviours.
Amended the code again, rather than just report it to MQ2 window, but now return clean ( true ) from the Equip procedure if the "ask" and "in place" are of the same item ID, before any searching in bags or swaps of items get done.
This next test run, my MQ2 Window comments are there (for debug evaluation only, so I know its this new build), and that cursor flicker, the inventory changes have stopped.
The second shield remained in position, in a lower down inventory slot and did not move as it had done prior to code change.
Happy days!
This should also reduce that chance of the "attune" feature as well. i.e. if already have "item" equipped and attuned, it wont try to use one from the inventory of the same name, as the Equip will return before it gets the chance to.
Regards and Best Wishes
Hi guys
Just thought it best to update you with this thread and the plugin as there has been some activity these last few days!
Various things written about, some code changes and as you can see today Redbot has pushed a new build out!
Regards and Best Wishes
Just thought it best to update you with this thread and the plugin as there has been some activity these last few days!
Various things written about, some code changes and as you can see today Redbot has pushed a new build out!
- Knights 2H Bash - This code is in, for those Knights with lvl 59 AA "Improved Bash" and using 2 hander weapon
- Warrior 2H Bash - This is back in, for the Warriors with lvl 105 AA "Two-Handed Bash" and using 2 hander weapon.
- In combat item swaps - this code is not in, its in git yesterday but pending approval and merge. ( as wrote about yesterday, this is to stop equip item from bags with the same ID as already equipped, leading to items on cursor, attune pop-up spam etc).
Regards and Best Wishes
Redbot updated MQ2Melee with a new update entry:
Stop unecessary item swaps in combat (Equip same ID from bags already in target slot)
Read the rest of this update entry...
Stop unecessary item swaps in combat (Equip same ID from bags already in target slot)
Read the rest of this update entry...
Are you saying that the paladin is under level 59 ?
Paladin fighting with a 2H weapon is trying to bash, and what does it say, talk of equip a shield perhaps?
Can you say how your paladin is being controlled please. Are you using a macro, like KissAssist ?
Really could do with more information.
I would also like to ask you to take your paladin to a lower level zone, alone, and without any macros running, find some trash and play whack-a-mob on it.
Simply put target, stand close and press attack. Let the melee plugin drive.
Please report back the experience of what happens.
Sure thing.
Using muleassist.
Paladin is currently level 54, without any AAs
I typically start in 1H with Shield, and will periodically switch bandolier sets between the 1H/2H manually.
Upon switching to the 2H weapon, it will try to use the bash skill and get the EQ skill error of something to the effect of "You need to equip a shield in order to BASH" repeatedly.
I 'suspect' mq2melee is the cause, because if I do /melee bash off it will stop the error messages, but also disables bash for when I switch back to 1H/shield
Using muleassist.
Paladin is currently level 54, without any AAs
I typically start in 1H with Shield, and will periodically switch bandolier sets between the 1H/2H manually.
Upon switching to the 2H weapon, it will try to use the bash skill and get the EQ skill error of something to the effect of "You need to equip a shield in order to BASH" repeatedly.
I 'suspect' mq2melee is the cause, because if I do /melee bash off it will stop the error messages, but also disables bash for when I switch back to 1H/shield
Without a macro running, with a 2h weapon equipped, it still attempts to use the bash skill.
Tried doing an unload/load of mq2melee with the 2h weapon equipped at the start to see if it was holding a variable, but it behaved the same way.