Although it's easier, it also produces more garbage, so no.
Just use a local function(...) do iterate, a fake_ipairs, so to speak, like in my example.
so i have to call it multiple times instead of just once if i need to process the results more than once, which i do (i need to cycle through them twice). nvm, i'll stick to my original code and change it when yours does.
If you want to take the garbage hit, just do local x = { ClosetGnome:GetOutfitsUsingItem(itemName) }, and you have your precious table.
Oh, and my code wont change, so good luck waiting for that.
If you want to take the garbage hit, just do local x = { ClosetGnome:GetOutfitsUsingItem(itemName) }, and you have your precious table.
no problem, i'll take the hit, and my "precious table". LUA has good GC and i don't particularly care.
please realise that not all of us know LUA perfectly, or even that well. i only ask for things the way i know they work. i did not know you could reverse the unpack by using table brackets (i could not find a way to turn them back into a table when i searched), thats why i asked for the table.
i did not know you could reverse the unpack by using table brackets (i could not find a way to turn them back into a table when i searched), thats why i asked for the table.
r32791:
Would it be possible to get an option to disable the:
self:Print(string.format(L["In combat: %s queued for swap."], name))
I use the switcher, and on my rogue I have a dagger in main hand so I can backstab. And then switch weapons to swords when fighting.
The sets only contains the weapons(I have set all the slots to red except for the two weapon slots).
Same thing happens on my warrior with stances, also here the involved sets only contains weapons.
Would love to avoid the queued-message(or a nice in-game option to remove that).
Thanks for a great addon.
Any news about that bug? This also happens when I change from my 2hand to 1hand+shield with my warrior while in combat. The sets only contains weapons(+shield).
First of all, thanks for this really great addon (love the messages it does). Any chance that different profiles will be implemented once? I just started a druid where I need to switch healing/tanking gear, but it only works global, not for different characters yet. Would be awesome to see this. Or did I just miss something?
Greetings.
p.s.: and sorry if this question was answered already, didn't have the time to read the last 30 pages oO
CG module that emulates ItemRacks "pop-out" functionality on the character screen, where when you shift+hover over a particular item slot (head, neck etc) it will display a pop-out where you can select other items in your bags using the same slot. I will seriously have your babies if you add a module that does that :)
Still getting that error I reported on June 20, page 29:
[2007/07/08 23:15:18-1680-x1]: ClosetGnome_Banker\Banker.lua:286: bad argument #1 to 'pairs' (table expected, got nil)
ClosetGnome_Banker\Banker.lua:286: in function `func'
Dewdrop-2.0-42392 (AHsearch):665: in function <...ace\AddOns\AHsearch\libs\Dewdrop-2.0\Dewdrop-2.0.lua:604>
FYI, weapon swapping from a two-hand weapon to a one-hand weapon plus a "held in off-hand" miscellaneous item isn't working quite right (read: at all). Remember that "held in off-hand" items don't come back as INVTYPE_WEAPON, they're INVTYPE_HOLDABLE.
I made a hack for ClosetGnome:EquipItem based on the shield hack a few pages ago:
-- holdable change starts here... (from forum courtesy Ruldar
if slot == 17 and self:ItemNameFromSlot(16) then
local _,_,_,_,_,_,_,_,itemEquipLoc,_ = GetItemInfo(self:ItemNameFromSlot(16))
if itemEquipLoc == "INVTYPE_2HWEAPON" then
PickupInventoryItem(16)
local toBag, toSlot = self:LocateFreeSlot()
if toBag ~= nil then
PickupContainerItem(toBag, toSlot)
else
AutoEquipCursorItem()
end
end
end
-- ...and ends here
I suspect there is a better way to fix it, but I don't have the time right now. I'll look in to it tomorrow if I get a chance.
Thanks, please do take a look at it and feel free to provide me with a proper patch for it. This issue does not interest me much, so I've been hoping someone else would fix it for quite some time :P
So I looked in to it, and actually I think that probably is the best way to do it. Because of the way the set tables are built, and then interated, there's no elegant way to say "if I'm looking at slot 17, but slot 16 hasn't been handled yet, do slot 16," which is how I'd prefer to do it. Since we can't do that without overhauling set construction (or forcing ReallyWearSet() to do slot 16 first, which would be messy and mean rewriting a bit of ReallyWearSet()), the only way left is to make sure that slot 16 doesn't have a 2h weapon in it when we try to equip slot 17, which is exactly what the hack above does.
So, I cleaned it up a bit, and here is a revised clipping from ClosetGnome:EquipItem():
...
table.insert(deequipQueue, slot)
end
else
-- 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 wpnisTwoHand = self:ItemNameFromSlot(16) and ( self:GetItemEquipLoc(self:ItemNameFromSlot(16)) == "INVTYPE_2HWEAPON" )
if slot == 17 and wpnisTwoHand then
PickupInventoryItem(16)
local toBag, toSlot = self:LocateFreeSlot()
if toBag ~= nil then
PickupContainerItem(toBag, toSlot)
else
AutoEquipCursorItem()
end
end
local bagNum, slotNum = self:FindItem(item)
if bagNum > -1 then
...
NOTE: I'm at work, and can't actually test that code, but I'm pretty sure it should work. Just make sure it does before you commit it... I will test it over lunch (sometime after noon Pacific time), but until then you're on your own. ;)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
If you want to take the garbage hit, just do local x = { ClosetGnome:GetOutfitsUsingItem(itemName) }, and you have your precious table.
Oh, and my code wont change, so good luck waiting for that.
no problem, i'll take the hit, and my "precious table". LUA has good GC and i don't particularly care.
please realise that not all of us know LUA perfectly, or even that well. i only ask for things the way i know they work. i did not know you could reverse the unpack by using table brackets (i could not find a way to turn them back into a table when i searched), thats why i asked for the table.
thankyou for your help.
Now you know :)
if type(input) ~= "string" then return end
to this
if type(itemLink) ~= "string" then return end
thanks
Done anyway.
yes, i do, but it's your mod and you're still here, so i ask first. thanks for the fix.
You can remove it manually, just read the readme.txt.
It won't go away until swapping 1h+shield <-> 2h, identical trinkets, and stuff like that, works 100%.
for i, item in ipairs(items) do
to
for i, item in pairs(items) do
looks like there can be nil's in the table (the index is not entirely sequential) resulting in it not picking everything up.
If I was using Arkinventory, I would just commit to it without asking you at all, and I wouldn't even post in the forum thread.
But yeah, fixed.
Any news about that bug? This also happens when I change from my 2hand to 1hand+shield with my warrior while in combat. The sets only contains weapons(+shield).
Greetings.
p.s.: and sorry if this question was answered already, didn't have the time to read the last 30 pages oO
CG module that emulates ItemRacks "pop-out" functionality on the character screen, where when you shift+hover over a particular item slot (head, neck etc) it will display a pop-out where you can select other items in your bags using the same slot. I will seriously have your babies if you add a module that does that :)
It's in the files.
Guess i missed this.. Thanks :)
I made a hack for ClosetGnome:EquipItem based on the shield hack a few pages ago:
I suspect there is a better way to fix it, but I don't have the time right now. I'll look in to it tomorrow if I get a chance.
So, I cleaned it up a bit, and here is a revised clipping from ClosetGnome:EquipItem():
NOTE: I'm at work, and can't actually test that code, but I'm pretty sure it should work. Just make sure it does before you commit it... I will test it over lunch (sometime after noon Pacific time), but until then you're on your own. ;)