Authors CurseForge

Quote from mozul »

However, ClosetGnome will NOT swap in arrows or bullets during combat while the user can manually do it during combat.

Think I fixed that now, thank you.

When ClosetGnome goes to equip your off-hand, if the weapon meant to be equipped there is in your main-hand, you will receive an error that it couldn't find the item (obviously, it's in your main-hand). I have a small patch that fixes this, but it's at home. I will post the small code snippet tonight.

Be sure to click on all items in the set that glow yellow on the character frame... the yellow slots are inactive and will not be updated.

Alright, here is that small weapon switch patch:

Basically, in ClosetGnome:EquipItem, you have a check to see if your MH has a two handed weapon in it. I extended that check, and added another small block of code at the end to make ClosetGnome attempt to requip the off-hand (the comment explains more). You do not have to do the inverse for an off-hand -> main-hand switch because the off-hand is removed first. Though, it may still experience the race condition I describe in my second comment. I haven't tried to test it yet.

-- Tegan @ Whisperwind: 12/12/2007: Added an or and a small if at the end of this block to handle the case where your new offhand is currently
-- in your mainhand (which is unequiped after the off-hand is handled)
if slot == 17 and ((self:ItemNameFromSlot(16) and ( self:GetItemEquipLoc(self:ItemNameFromSlot(16)) == "INVTYPE_2HWEAPON")) or self:ItemNameFromSlot(16) == item) then
	-- We can't equip off-hand items if we still have a 2h weapon equipped. In such an event, we should deequip the 2h weapon first.
	local oldMainhand = self:ItemNameFromSlot(16)
	
	PickupInventoryItem(16)
	local toBag, toSlot = self:LocateFreeSlot()
	if toBag ~= nil then
		PickupContainerItem(toBag, toSlot)
	else
		AutoEquipCursorItem()
	end
	
	-- Tegan @ Whisperwind: If we just unequiped our MH because it was our new off-hand, schedule this and return because it takes a fraction
	-- of a second for the item to actually hit your inventory (this call needs to exit and come back at the very least). This may be a race 
	-- condition situation, but scheduling the equip a second time, then returning works. The only "side effect" is that all the rest of your
	-- set will equip before the new offhand pops in (which may actually be whats fixing the race, because it lets blizzard fully update your
	-- inventory)
	if oldMainhand == item then
		self:ScheduleEvent(self.EquipItem, 0.1, self, slot, item, false);
		return
	end
end

Quote from BorisTheBlade »

Screw it. I give up. I'm going to have to go back to using Outfitter I guess cause we are not getting any sort of response at all for this issue.

Do whatever the fuck you want, idiot. I don't get paid when you use my addons.

I have responded several times to the issue already, now stop making "threatening" posts in my thread.

Mod works fine here...

I removed the set hiding from CG_Mount now, since it seems to have confused too many people.

The whole idea was that CG_Mount should handle when to equip and deequip those sets anyway, so there's no reason to have them visible in the switcher interace.

I'm going to add options where you can manually toggle the visibility of each set from the switcher tablet instead, and just have sets called "Mount", "Dismount" and "Flight Form" hidden by default.

Hopefully I'll get it done soon.

That's how it works already.

Just make sure you've toggled all the non-swappable items red in the set config screen.

I guess it's possible that the check for it doesn't work 100% now since I haven't coded in any delays for the checks (like waiting for item lock updates), but I haven't had any problems with it myself.