local function pairsByKey (t, f)
local a = {}
for n in pairs(t) do table.insert(a, n) end
table.sort(a, f)
local i = 0 -- iterator variable
local iter = function () -- iterator function
i = i + 1
if a[i] == nil then return nil
else return a[i], t[a[i]]
end
end
return iter
end
...
function foo()
local bar = {
["key1"]="value1",
["key2"]="value2",
["key3"]="value3",
}
for k, v in pairsByKey(bar) do
dostuffwith(k, v)
end
end
I have no idea if what I do leads to a lot of garbage or not, it does a nice job of hiding the complexity in the iterator so that the code itself looks simple...It has the added advantage of allowing for a sorter to be passed as a second argument.
Similarly I use the same principle to iterate over a raid/party :
local function RaidIterator()
local i = 0
return function ()
i = i + 1
local unit
if UnitInRaid("player") and i<=GetNumRaidMembers() then
return "raid"..i
else
numPartyMembers = GetNumPartyMembers()
if i<= numPartyMembers then
return "party"..i
elseif i==numPartyMembers+1 then
return "player"
end
end
end
end
I have released a new version correcting the heals appearing as crit since a few patches. Additionally I have released Acheron_Graph which gives a graphical vision of what happened to the unit and when.
On a side note Skada_FriendlyFire is now correctly packaged and should work flawlessly... Should it work less than flawlessly you are authorized to blame drugs, as a second step you may open a ticket on the project page...
I'm under the impression the problem occurs when the children of a container are almost filling the container or actually filling a bit more than the container... What was weird with my bug was that if I actually clicked on the scrollbar the freezing stopped...
I solved it the same way you did : by adding an empty filler element...
I have written a module that adds a friendly fire damage mode (Skada_FriendlyFire), it is still in experimental status but as soon as I can test it properly I will release it. It will add some data into the set / player objects, as I understand it it is the way to go about such things (for player object data is friendly fire damage done amount, as well as amount for each raid member targetted / spell used).
First question : is it all right with you if I do that ?
Second question : if you could go over my code and tell me if it's up to par with your standards I would be grateful. Specifically I could not find a way to use the existing framework and say that I was interested in the events that had dst AND src as raid members so I have to parse more events than I should, I do it in such a way that should not be more demanding on resources than if it was coded in the framework but I may have missed something.
There are different ways to access Acheron, the most used ones are :
- Open Acheron through the Launcher, a /command => Acheron opens without any character being filtered
- Right click on any unitframe and select Show Death report => Acheron opens with a filter on the character defined by the unitframe
I wanted to know the precise rules governing CHAT_MSG_LOOT in a raid environment and specifically : is the event always generated when someone in the raid loots something ? Is there a distance limit ? What if you are not in the same zone ?
I am in the process of writing a simple DKP addon for my guild, I will just record automatically attendance and loots with a way to edit both.
I thought at the beginning to just have one of the people in the raid to use the addon. The problem I am running into is if that guy disconnects, I am at risk of losing all the info for the night.
Any idea of a simple solution to work around that ? I toyed with two ideas :
- Is there a way I could manually force the commit on file of my AceDB ? Not sure if possible.
- A client / server solution where the server is re-negociated periodically, if server crashes one of the client takes over... Strikes me as quite complicated...
As a general rule you should only use the public API for a widget, no using of widget.frame or at least only in the purpose of reading things, it is the only guarantee you are not screwing things up for the next user.
Hint : instead of doing frame.frame:SetPoint, do frame:SetPoint()
As for your problem, test it but chances are that logging out will not fire OnClose script.
The solution to use the OnUpdate script is NOT a good one if I understand correctly the intricacies of wow...
I think you could open a ticket for Nev to add a OnMovementStart / Stop callback on the frame
0
I have no idea if what I do leads to a lot of garbage or not, it does a nice job of hiding the complexity in the iterator so that the code itself looks simple...It has the added advantage of allowing for a sorter to be passed as a second argument.
Similarly I use the same principle to iterate over a raid/party :
0
0
0
0
I solved it the same way you did : by adding an empty filler element...
0
0
First question : is it all right with you if I do that ?
Second question : if you could go over my code and tell me if it's up to par with your standards I would be grateful. Specifically I could not find a way to use the existing framework and say that I was interested in the events that had dst AND src as raid members so I have to parse more events than I should, I do it in such a way that should not be more demanding on resources than if it was coded in the framework but I may have missed something.
0
- Open Acheron through the Launcher, a /command => Acheron opens without any character being filtered
- Right click on any unitframe and select Show Death report => Acheron opens with a filter on the character defined by the unitframe
0
0
0
I swear this is another anglo plot to wrong us, cheese-eating surrendering monkeys :p
0
0
I thought at the beginning to just have one of the people in the raid to use the addon. The problem I am running into is if that guy disconnects, I am at risk of losing all the info for the night.
Any idea of a simple solution to work around that ? I toyed with two ideas :
- Is there a way I could manually force the commit on file of my AceDB ? Not sure if possible.
- A client / server solution where the server is re-negociated periodically, if server crashes one of the client takes over... Strikes me as quite complicated...
I do not like any of those solutions, help meee !
0
Hint : instead of doing frame.frame:SetPoint, do frame:SetPoint()
As for your problem, test it but chances are that logging out will not fire OnClose script.
The solution to use the OnUpdate script is NOT a good one if I understand correctly the intricacies of wow...
I think you could open a ticket for Nev to add a OnMovementStart / Stop callback on the frame
0