evil-morfar / rclootcouncil2 Goto Github PK

It happens when the character has never been awarded with any item, but is in the raid group. The name list should always show all raid members, regardless they was awarded once or not

@SafeteeWoW I made a quick implementation for your suggestion 7ce9f77.

For now, I don't intent to make db.announceItemString editable in game in RCLootCouncil.
It's currently untested, but it should work as intended.

Let me know if that covers your need.

1x RCLootCouncil\core.lua:2620: attempt to index field '?' (a nil value)
RCLootCouncil\core.lua:2620: in function GetButtonText' RCLootCouncil\Modules\lootFrame.lua:141: in function OnRoll'
RCLootCouncil\Modules\lootFrame.lua:271: in function <RCLootCouncil\Modules\lootFrame.lua:271>

I changed the Button options to only have Need or Greed, however it always defaults back to the standard options that includes the Minor Upgrade option, which is not what I want.

1. Award button is changed to "Cant Award:"..reason if cant award
2. The rightclick menu needs to be updated properly (every 1s) when opened?
3. Award button will be unclickable if cant award.
4. Hide or disable 'Award For" if cant award

I want to show socket/leech, avoidance, etc with ilvl.

The display is like
930/socket
930/leech

But in the current design, additional information need to be transmitted for the ML. I don't like it.

Although it would be a milestone for the next expansion, I just want to list the ideas for future reference.

Goal for RCLootCouncil3:

1. RCLootCouncil currently has too much redundant code. For example, many code copy&paste for relic/tier buttons can be avoided. Furthermore, inheritance can be used on many widgets for better code reusability. If I want to add a button type, I need to copy/paste/modify lots of code. It's not a good idea.
2. We should minimize the data transmitted in the lootTable. First, smaller=faster=better. Second, communication bug is always harder to find, test and solve and easier bugged. Third, more communication = harder backward compatibility. In my opinion, what really needed to be transmitted in the lootTable in "link" and "bagged". Although some data needs to be cached, there are so many ways to overcome caching. For example, while the item is being cached, voting frame shows the item name as "Retrieving item info"
3. The code should be structured to be allow feature to be added easily.
4. Always try to avoid to write localization related code.
5. I would like to have better button category customization. i.e., allowing user to define category in his own way, not limited to tiers and relics.

The current reconnect data is horific: comm string example (68,829 kB) Decoded table.

Currently the following data is sent on reconnects: MLdb > council >candidates > lootTable > reconnectData.

The first two are required to get ML's settings, and to know if we have access to votingFrame (but we could initially just send the ML and the reconnectee if council). LootTable (as normally sent by ML) is required if we want candidate to roll - it's also currently required in the live version to setup votingFrame (not necessary if changed). ReconnectData should then contain everything that's happened in the session(s), but currently it's just a copy of addon.lootTable meaning it's a mixture of all of the above.

A session entry example

["equipLoc"] = "INVTYPE_FINGER",
["haveVoted"] = false,
["awarded"] = "зулналан-Ревущийфьорд",
["link"] = "|cffa335ee|Hitem:152063::::::::110:64::3:4:3610:42:1472:3528:::|h[Печать мастера порталов]|h|r",
["texture"] = 1391741,
["typeID"] = 4,
["subType"] = "Разное",
["relic"] = false,
["subTypeID"] = 0,
["lootSlot"] = 4,
["name"] = "Печать мастера порталов",
["classes"] = 4294967295,
["ilvl"] = 930,
["boe"] = false,
["quality"] = 4,
["candidates"] = { ...}

So what's needed? If LootTable is sent first, then basically everything but awarded can be removed. That's probably the way to go.
Otherwise the following are required for the votingFrame without needing to cache: awarded, link, ilvl. Most things from GetItemInfoInstant() should also be included when received.

A candidate example

["авилинна-Ревущийфьорд"] = {
        ["haveVoted"] = false,
        ["ilvl"] = 942.9375,
        ["class"] = "ROGUE",
        ["response"] = "PASS",
        ["gear2"] = "|cffa335ee|Hitem:133637:5429:::::::110:259::35:3:3418:1592:3337:::|h[Перстень короля Утгарда]|h|r",
        ["voters"] = {
         },
        ["role"] = "DAMAGER",
        ["diff"] = 0,
        ["votes"] = 0,
        ["specID"] = 259,
        ["isRelic"] = false,
        ["gear1"] = "|cffa335ee|Hitem:133634:5429:::::::110:259::35:3:3536:1582:3337:::|h[Кольцо из цепкого щупальца]|h|r",
        ["rank"] = "Четвертый",
},

Assuming candidates are sent first, all things from there can be removed (class, role, rank). SpecID could technically be included from candidate data, although it might not be entirely up to date. To further reduce data, everything that's false or 0 can be nil and recreated when received. Finally, we don't need entire itemlinks (we honestly never need to receive that on player gear, except for the loot history, where it's quite nice to have), so those could be shorted to itemstrings.

Solution

New structure (1 session):

reconnect = {
  ["авилинна-Ревущийфьорд"] = {
     ["ilvl"] = 942.9375,
     ["gear2"] = {
     },
     ["gear1"] = {
          [1] = 1,
     },
     ["response"] = {
          [1] = "p",
     },
  },
...
["lookup"] = {
   [1] = "item:137487:5890::::::::::35:3:3418:1597:3337:::",
},
}

• Get rid of the lootTable overhead - it's already contained in the actual lootTable comm. Awarded isn't required either, it can be gathered from the response.
• Get rid of all unrequired data from candidates.
• ilvl can be sent once instead of with every session.
• Don't send isRelic or isTier - while not 100% ensured, these are almost guaranteed if tier/relic buttons are enabled.
• Use lookup tables:
  • Default system responses can be shortened to one letter. Autopass = true saves even more.
  • Items only have to be written once. Each time that item appears, substitute with it's table index. This does add more data if there's no duplicate items, but saves a lot if there are.

Doing this changes the data from 68,829 kB to 15,368 kB, another example from 43,758 kB to 7,965 kB.

Further optimizing

• LibCompress. Using the above examples 15,368 kB becomes: 8,493 kB, 7,965 kB becomes: 4,549 kB.
• Shaving realmname (bit of a gamble, technically there could be two people with the same name): saves 729 kB and 317 kB in my examples.
• Reducing table key names: 527 kB and 491 kB.
• Substituting/reducing colons from itemstrings. Will probably be around 3 bytes per item. 543 kB and 246 kB.

• No usage popup in LFD group. IsPartyLFG()
• Option to only use in raids.
• Better tooltip for "Loot Everything". Especially that it also mean relics.
• "MLdb_check" doesn't seem to work (SVs from ticket 174)
• Add a slight delay on the first mldb send, so clients have a better chance to detect ML.
• LootFrame buttons needs to be updated when mldb changes.

Mandatory

• - Personal Loot
• • - Changes to "Auto Loot BoE"
• - Trade Windows

Included if ready

• - Autopass owned items #153
• - Discord export
• - Optimize reconnect data #125
• - /rc add run by everyone #88
• - Loot Frame shows compare item #142
• - Better export filters

Nice to have, but might be pushed

• Export SV in game #134
• #143
• #147
• Mass deletion of Loot History
• #155
• #156

Curseforge issue tracker is bad and cant even solve a simple problem that file cant ends with .lua
Can you switch to Github issue tracker? There is a setting in Curseforge to change it. And copy and paste the comments of current open issues. And howto make issue template: https://github.com/blog/2111-issue-and-pull-request-templates

Tired of asking saved variables and teach people how to upload saved variabes.
We should make a feature to generate serialized form (probably not AceSerializer ) of saved variable and allow people copy and paste them in-game. This is easier.

It sucks to have so many places to talk about addon issues

1. www.curseforge.com
2. wow.curseforge.com
3. https://wow.curseforge.com/projects/rclootcouncil/issues
4. github

537c523 including player data in lootAck is the next logical step. I tried to do some worstcase tests, and with 5 items one SendCommand is called with a payload of 425 bytes, vs 5 commands with a combined payload of 790 bytes + 1 command with the lootAck.

The change is also somewhat backwards compatible - as long as the ML and councilmember has this version there should be no issues.

Here is my FrameXML.log
8/8 16:54:48.546 Loading add-on RCLootCouncil
8/8 16:54:48.546 ** Loading table of contents Interface\AddOns\RCLootCouncil\RCLootCouncil.toc
8/8 16:54:48.546 ++ Loading file Interface\AddOns\RCLootCouncil\embeds.xml
8/8 16:54:48.546 ++ Loading file Interface\AddOns\RCLootCouncil\Libs\DropDownMenu\UIDropDownMenuTemplates.xml
8/8 16:54:48.546 Deferred XML Node object named Lib_UIDropDownMenuButtonTemplate already exists
8/8 16:54:48.546 Deferred XML Node object named Lib_UIDropDownListTemplate already exists
8/8 16:54:48.546 Deferred XML Node object named Lib_UIDropDownMenuTemplate already exists

If I search for Lib_UIDropDownMenuButtonTemplate in my addon folder I find a list of these addons

• AutoTurnIn (disabled)
• ElvUI (enabled)
• MoveAnything (enabled)
• RCLootCouncil (enabled)

Do you know any good editor that can debug Lua 5.1?
I have tried a lot, and the only one I have found that actually works is LuaStudio, but it costs $35.

Pawn basically is an addon that lets you see how good an upgrade is (in %) based on your stat weights, if there was a way to perhaps add some sort of pawn support so the loot master could see how good an item is for someone besides just ilvl that would be really useful.

When the addon asks usage for leader, usage is asked once when I become the leader, and then another immediately after when it switches me to Master Looter. Don't know why this does not occur when testing in 2man group.

This is a minor one, mostly UI improvement if nothing else, but annoying for someone with an OCD like me :).

When you have buttons configured with labels like: "BiS", "Tier/WF", "Main", "OS", "Transmog" the sizes of buttons are very different. This does make sense to the extend that labels are different in width, but it's very disturbing when ML configured it like above and I have also made window size smaller (as its just oversized for me right now).

Suggestion: maybe there should be a minimal reasonable width for buttons that matches 4-5 character width of the label? This would make "BiS", "OS", and "Main" buttons have same width, with others being a bit wider.

Currently relics are auto-passed even if you could use it in one of your offspec weapons. I'm not sure if there is a better way than defining what each class can use. If there is not, maybe this saves you some research: https://github.com/mlsen/raidcomp/blob/master/frontend/app/scripts/misc/wow.js#L236 (created for a different project).

Also thanks, appreciate your hard work on this!

3x RCLootCouncil\Libs\lib-st\Core.lua:587: attempt to index local 'rowdata' (a nil value)
RCLootCouncil\Libs\lib-st\Core.lua:587: in function GetCell' RCLootCouncil\Libs\lib-st\Core.lua:660: in function OnLeave'
RCLootCouncil\Modules\versionCheck.lua:180: in function <RCLootCouncil\Modules\versionCheck.lua:178>

Some early preview of BFA API changes:
I dont have Alpha access, and I just had a look at UI source exported by other: https://github.com/tomrus88/BlizzardInterfaceCode

Obviously, the API hasn't been completed.

There are more C_XXX functions added. The most interesting ones are:
C_Item

In FrameXML/ObjectAPI/Item.lua, some useful utility functions related to item info are added.
"ItemEventListener" -- Request item info and run callback when the item info is fetched.

I like the objective code style in ObjectAPI folder. This is the way to go in RCv3.

Dont want to have RC popup and dont even want RC enabled in (premade) arena or battleground.
If I entered arena as raid group and when I am the first one who loaded into the arena, I keep getting RC popup, which is annoying.
should be very simple to fix

There's a small potential for throwing away data with the current lootTable caching system. Consider this log from a recent raid of mine:

"20:15:50 - Comm received:^1^SlootTable^T^N1^T^N1^T^SequipLoc^SINVTYPE_HAND^Sawarded^b^Slink^S|cffa335ee|Hitem:152012::::::::110:104::5:3:3611:1512:3337:::|h[Molten~`Bite~`Handguards]|h|r^Srelic^b^Stexture^N1605809^SsubType^SPlate^SlootSlot^N3^Sclasses^N4294967295^Sname^SMolten~`Bite~`Handguards^Sboe^b^Silvl^N970^Squality^N4^t^N2^T^SequipLoc^SINVTYPE_TRINKET^Sawarded^b^Slink^S|cffa335ee|Hitem:151974::::::::110:104::5:4:3611:3618:1497:3336:::|h[Eye~`of~`Shatug]|h|r^Srelic^b^Stexture^N463857^SsubType^SMiscellaneous^SlootSlot^N2^Sclasses^N4294967295^Sname^SEye~`of~`Shatug^Sboe^b^Silvl^N955^Squality^N4^t^N3^T^SequipLoc^S^Sawarded^b^Slink^S|cffa335ee|Hitem:152291::::::::110:104::5:3:3611:1492:3336:::|h[Fraternal~`Fervor]|h|r^Srelic^SLife^Stexture^N459025^SsubType^SArtifact~`Relic^SlootSlot^N1^Sclasses^N4294967295^Sname^SFraternal~`Fervor^Sboe^b^Silvl^N950^Squality^N4^t^t^t^^ (from:) (Barrow) (distri:) (RAID)", -- [1356]
"20:15:50 - Comm received:^1^SlootAck^T^N1^SEliarra-Ravencrest^N2^N258^N3^N961^N4^T^Sresponse^T^N1^B^N2^B^t^Sdiff^T^N1^N25^N2^N5^N3^N0^t^Sgear1^T^N1^Sitem:152155::::::::110:258::5:3:3611:1487:3528^N2^Sitem:151962::::::::110:258::3:3:3610:1492:3337^t^Sgear2^T^N2^Sitem:151955::::::::110:258::5:3:3611:1492:3336^t^t^t^^ (from:) (Eliarra) (distri:) (RAID)", -- [1357]
"20:15:50 - Comm received:^1^SlootAck^T^N1^SValhorth-Ravencrest^N2^N262^N3^N964.3125^N4^T^Sresponse^T^N1^B^N2^B^t^Sdiff^T^N1^N-30^N2^N20^N3^N0^t^Sgear1^T^N1^Sitem:151819:5444:::::::110:262:::2:1811:3630^N2^Sitem:154177::::::::110:262::3:2:3985:3993^t^Sgear2^T^N2^Sitem:151955::::::::110:262::3:3:3610:1477:3336^t^t^t^^ (from:) (Valhorth) (distri:) (RAID)", -- [1358]
"20:15:50 - Comm received:^1^SlootAck^T^N1^SBenó-Ravencrest^N2^N251^N3^N960.5^N4^T^Sresponse^T^N3^B^t^Sdiff^T^N1^N25^N2^N-10^N3^N0^t^Sgear1^T^N1^Sitem:152114::::::::110:251::5:3:3611:1487:3528^N2^Sitem:137459::151583::::::110:251::35:4:3536:1808:1617:3337^t^Sgear2^T^N2^Sitem:154176::::::::110:251::3:2:3985:3991^t^t^t^^ (from:) (Benó) (distri:) (RAID)", -- [1359]
"20:15:50 - Comm received:^1^SlootTable^T^N1^T^N1^T^SequipLoc^SINVTYPE_HAND^Sawarded^b^Slink^S|cffa335ee|Hitem:152012::::::::110:104::5:3:3611:1512:3337:::|h[Molten~`Bite~`Handguards]|h|r^Srelic^b^Stexture^N1605809^SsubType^SPlate^SlootSlot^N3^Sclasses^N4294967295^Sname^SMolten~`Bite~`Handguards^Sboe^b^Silvl^N970^Squality^N4^t^N2^T^SequipLoc^SINVTYPE_TRINKET^Sawarded^b^Slink^S|cffa335ee|Hitem:151974::::::::110:104::5:4:3611:3618:1497:3336:::|h[Eye~`of~`Shatug]|h|r^Srelic^b^Stexture^N463857^SsubType^SMiscellaneous^SlootSlot^N2^Sclasses^N4294967295^Sname^SEye~`of~`Shatug^Sboe^b^Silvl^N955^Squality^N4^t^N3^T^SequipLoc^S^Sawarded^b^Slink^S|cffa335ee|Hitem:152291::::::::110:104::5:3:3611:1492:3336:::|h[Fraternal~`Fervor]|h|r^Srelic^SLife^Stexture^N459025^SsubType^SArtifact~`Relic^SlootSlot^N1^Sclasses^N4294967295^Sname^SFraternal~`Fervor^Sboe^b^Silvl^N950^Squality^N4^t^t^t^^ (from:) (Barrow) (distri:) (RAID)", -- [1360]		

It's possible for lootAcks to arrive between the 1 frame recall to OnCommReceived. This causes the acks to be applied to a previous session, as VotingFrame:Setup() is called later, thus briefly showing candidates as "timeout" until their response arrives, but still doesn't show their equipped gear or potential autopass. It happens very rarely (I believe I've seen it ~5 times so far), but is an issue nonetheless.

As of right now, afaik, RCLootCouncil does not require any items to be cached, so the easiest solution is to do the GetItemInfo calls to prompt the cache, but without doing anything if it's not cached. This still caches (as per our tests) all items within the next frame - the only issue with that is if anything anywhere assumes the items are cached within that 1 frame.

A few other solutions

1. Cache incoming lootAcks and probably also responses. This is somewhat tricky, as there's currently no way of knowing which lootTable a particular lootAck belongs to, which I believe is required to ensure it's only applied the right place/time.
2. Delay everything but VotingFrame:Setup() at least 1 frame. This would hardly be noticeable for anyone, but is a delay, and somewhat annoying to do.
3. Make sure everything that needs cached item info won't crash without it. This should honestly already be implemented, and imo is the best of the 3.

I've been postponing this for a while, but finally got around to do it. I might as well do it properly while I'm at it, so here's a short heads up for v2.7.6:

I wanted to enhance the formatting of the output by colorizing the command, hence a need to change to current structure. I created a new function (RCLootCouncil:ModuleChatCmd()) so it doesn't overlap with the old format, which is still supported.

Here's the implementation from GroupGear to make the switch whenever the user upgrades:

if addon:VersionCompare(addon.version, "2.7.6") then
   addon:CustomChatCmd(self, "Show", "- gg - Show the GroupGear window (alt. 'groupgear' or 'gear')", "gg", "groupgear", "gear")
else
   addon:ModuleChatCmd(self, "Show", nil, "Show the GroupGear window (alt. 'groupgear' or 'gear')", "gg", "groupgear", "gear")
end

There are lots of coding structure problems in v2.x

1. File is too large
2. Strange module management.
3. lots of redundant code for GUI
4. No UnitTest framework.
5. etc

I have signed up TradeSkillMaster4 Beta and read its blog, trying to figure out the solution.
See also https://blog.tradeskillmaster.com/classes/

http://pastebin.com/xYAkH8AY - the loot session
http://puu.sh/rA3VC/8e7db3b80e.jpg - how it looked

They have the lastest version, and so do the ML.

If you need anything else just tell me. :)

Just a thread to discuss some changes for 2.7

I changed the layout/text for the descriptions in cdb4600, but I'm not sure if it could be better still. Any inputs @SafeteeWoW ?

By comparing the raid lockout before the encounter and after the encounter, whether or not the player is eligible for the loot can be known.

GetMasterLootCandidate is another way to check this, but this occasionally changes when a raider leaves instance and is still eligible for the loot, at least when I tested it in Patch 7.3 (before 7.3.5) I have never done any loot tests since 7.3.5, because I can no longer master loot in old dungeons.

1. If the player is not locked to the boss and is locked to the boss after it is dead, the player is eligible for the loot, respond to ML normally.
2. If the player was locked to the boss before the instance, autopass by sending "SAVED" to the ML.
3. If the player wasn't locked after the encounter, autopass by sending "OUT" to the ML.
4. We only do the above check when the item is BoP.
   5.Out of instance response will be deprecated after the full implementation of this feature.

Such information can be gathered from the following API:
GetSavedInstanceInfo, GetNumSavedInstances, GetSavedInstanceEncounterInfo
RequestRaidInfo RequestLFDPlayerLockInfo

For more reference, read FrameXML/RaidFrame.lua and the addon SavedInstances

There are several challenges for this feature:

1. (a)Award Later list should maintain the boss which the item belongs to, otherwise this does not work if ML awards many items later, or (b) we hardcode the boss-item relationship. This is probably a better bug-free version. I think there is already an addon which has implemented this feature, and it's not hard for me to dump this information from the Encounter Journal, just need some disk space to store such information in the source code. ~~~Also needs to generate a table to translate between Encounter Journal id and ENCOUNTER_START/ENCOUNTER_END id, which possibly can be done by parsing DBM/BigWigs source code?~~~ (Probably not needed)
2. The recent saved instance information should be recorded in the SV for every raider, so the autopass by lockout can be sent correctly if ML does award later.
3. There could be a delay between the boss kill and the registration of lockout. The duration of the delay should be tested by experiment. If the session is started immediately after the end of encounter, we can delay the response by several seconds to solve this problem.
4. Privacy issue. DBM can fetch all lockout information from raiders too, but raider won't send this information unless confirm by clicking the dialog. Therefore, RCLootCouncil never sends all lockout infomation. It only sends information for the most recent encounter. Since most of the time, ML can know the lockout information by reading the master loot list anyway, it is not a privacy leaking.

Why this feature:

1. In the guild gold run, conveniently check who has the lockout. My guild offers less gold for ppl without fresh lockout, I check this through Master Loot List, which is most likely correct, but it is not convenient. (Another suggestion, If the raider does not have RC installed, and he is not in the Master Loot list, mark the response as ineligible for the loot?)
2. For general heroic guild ML/PL run, it is convenient, as often several people doesn't have the fresh lockout.

Can you show the secondary stats (Critical/Mastery/Versatility/Haste) of the item in white text (These stats is colored in white in tooltip, so I recommend to color them in white text) in votingframe and the lootframe? The value doesn't need to be shown. This could be very convenient.

Some adjustment to other widget is needed.

Sample display is
Critical/Mastery (The stat with higher value is shown first, more crit than mastery)
Mastery/Critical (More mastery than crit)

WoW API for this feature:

1. GetItemStats (Item needs to be cached)

Constants:

1. ITEM_MOD_HASTE_RATING_SHORT
2. ITEM_MOD_MASTERY_RATING_SHORT
3. ITEM_MOD_CRIT_RATING_SHORT
4. ITEM_MOD_VERSATILITY
   These constants is the key of the table returned by GetItemStats.
   Its localized text can be fetched from , for example, _G["ITEM_MOD_HASTE_RATING_SHORT"]

Not a difficult feature to implement, the issue is just how to properly adjust the display.

Due to the problematic case handling of RCLootCouncil:UnitName(), this does not work for Russian.

My fix:

strfind(self.masterLooter:lower(), _G.UNKNOWNOBJECT:lower())

A little heads up on some "breaking" changes I made:

• 1 Comm channel
  • It didn't make much sense having a ML comm, as most things received here needed to be received by everyone. Otherwise stuff had to be sent twice.
• Candidates index
  • Candidates are now bundled in self.lootTable[session].candidates. Not really needed, but it just makes things more organized, and generally easier to handle.
• SendCommand()
  • There's only one now (in core.lua) and it now takes "group" instead of "raid". Passing "group" as target relays the message to either "raid", "party" or "self" depending on GetNumGroupMembers(). While initially a quick fix for handling tests (as I want everything to go through OnCommReceived()), it also allows the addon to be used in a party.

• Auto close when all items awarded
• Monks shouldn't autopass on maces
• Show roll column values to everyone

I want to make the voting frame somewhat lighter in appearance, and have tried to do so with the current build. I'm just not sure whether I like it or not. You can do a /rc test # do emulate a session (should be working, except for a weird "OnCommReceived doesn't exist" error).

Some thoughts:

• Colors
• I went with something fresh and new, but I intend to make it customizable as it's quite simple to do so now that frames are made unanimously.
• More info
  • I guess most people don't really use the whole selection thing on the live version, but I still want somewhere to put any extra info that doesn't do into the table, or simply the larger icon for those who wants it. My intention is to have this toggable window display this.

I'd appreciate your thoughts on this so far.

It appears that GetLootSlotInfo may return nil quality some time. I'm not sure how to deal with it. Terminate the LootOpened when this happens, or delay by 1s then rerun the function?

The line number of the following is from the current master commit: ca5a9e6

1x RCLootCouncil\ml_core.lua:1299: attempt to compare number with nil
RCLootCouncil\ml_core.lua:1299: in function `ShouldAutoAward'
RCLootCouncil\ml_core.lua:779: in function `LootOpened'
RCLootCouncil\ml_core.lua:747: in function `OnLootOpen'
RCLootCouncil\core.lua:1726: in function `?'
...ACU\Libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:145: in function <...ACU\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:145>
[string "safecall Dispatcher[2]"]:4: in function <[string "safecall Dispatcher[2]"]:4>
[C]: ?
[string "safecall Dispatcher[2]"]:13: in function `?'
...ACU\Libs\CallbackHandler-1.0\CallbackHandler-1.0-6.lua:90: in function `Fire'
...xternal\Wildpants\libs\AceEvent-3.0\AceEvent-3.0-4.lua:120: in function <...xternal\Wildpants\libs\AceEvent-3.0\AceEvent-3.0.lua:119>

Locals:
nil

We always need to check the tooltip of the item. Why not always show it?
An awful PS as an example for votingFrame. Should also do it on the loot frame.

Before next expansion, I will release two standalone libraries. One serializer and one compressor, which generates significantly smaller data than the currently commonly used AceSerializer and LibCompress.

1. The planned name of those libraries:

   1. RCSerializer
      Not sure. Should I call this RC? Less readable than AceSerializer, but produce much smaller data by string reuse and several other small improvements. I was planning to implement a special optimization targeting item string, but it's not very needed with the help of a compressor, and it's not good for an general library.
   2. LibDeflate
      (Or call this RCCompressor? )A compressor uses DEFLATE algorithm. (See RFC1951). A litle bit slower, but provides much smaller data, especially if there are lots of redundancies.

2. The perfomance of LibDeflate

   1. The overhead of LibDeflate is of course bigger than LibCompress. So small data suitable within one WoW message (255 bytes) including header will not be compressed, to save CPU time. (Storing 5 extra bytes as header, without actual compressing, still following DEFLATE spec)
   2. This library is unfinished. I haven't implement decompressor. The correctness of compressor part is checked by the help of an external decompressor.

smalltest.txt
This a reconnect data serialized by RCSerializer. The original size is 28459 bytes.

LibCompress: 37ms, 18595 bytes, 65.3% of original
LibDeflate: 73ms, 10872 bytes. 38% of original, 57% of LibCompress.
gzip -1: 40ms(including loading and IO time, so not that useful), 7539 bytes
gzip -1: 44ms(including loading and IO time, so not that useful), 5873 bytes.

There are still lots of room to improve compression ratio and speed.

3. The performance of RCSerialzer was mentioned in #116, and I have another good idea to reduce the serialized size of nested table.

   {{link=A, bagged=B}, {link=C, bagged=D}} will be serialized similar to { link, bagged, {A, B}, {C, D}}

1. Suggestion to the name of those libraries? (Haven't pushed the code. It's too unfinished.)
2. Opinion to the performance.
3. Can you provide any more test data?

If you have time, can you help to compare the performance of the following IN-GAME?
All of the following needs to be executed many times to make a difference, but there is difference

1. bit.rshift(x, 8) VS (x-x%256)/256 (Dont forget to localize bit.rshift)
2. bit.lshift(x, 8) VS x*256 (Don't forget to localize bit.lshift)
3. bit.band(x, 255) VS x%256 (Don't forget to localize bit.band)
4. table.insert(t, x) VS t[#t+1]=x. Dont forget to localize table.insert
   My current observation is that the performance of function is always worse than its non-function equivalence.
5. string.char(x) vs byteToCharTable(x), where byteToCharTable is a pre-generated table such that byteToCharTable[i] == string.char(i), for i=0..255, Dont forget to localize string.char

Hi, I am planning a web app for presenting data from rclootcouncil exports. Is this available somewhere? I am unfortunately unable to generate this myself.

Just let you know. Happens randomly to random people

During today's raid, I cant give item to a druid named "Fallenminos-Illidan".
It says

unable to give [itemlink] to feral -{player offline, left group  or instance?}

It seems the druid's name is wrongly recognized as "feral".
However, I can confirm that he's in the instance, and I can award him the item using the default Blizzard loot frame.

Reload does NOT fix the problem.
Problem happens too if I use the RCLootCouncil award button instead of RCLootCouncil-EPGP award button

Hi, can tou add feature for filtering loot history by item name?

If the player has no free space to carry the item being rolled.

1. All non-pass buttons will be grey out and disabled.
2. Mouseover any button (include PASS) shows a tooltip to tell the player to clean the bag. OR change the ilvl text or item name text to tell the player about this?
3. When the bag has free space, button will be enabled again.

After this change, ML will rarely fail his loot distribution because some1's bag is full.

Side effect: This could slow down the response process.
So alternatively and more easier, we can choose not to bother with the buttons, and one of the following:

1. Give a big warning when non-pass response is chosen while the bag is full.
2. Big text in the title of the loot frame when the bag is full.

I am asking if you have interest to create a RCLootCouncil Discord Server.
My Discord ID is Safety#1191

The server can make the following discussion more convenient and be involved by more people

1. New Feature Announcement
2. Bug Report
3. Feature Suggestion
4. We can discuss implementation detail with more people.
5. Loot Distribution Rule Discussion (Loot Council, DKP, EPGP)

If you are interested, please create the server and add the server link to Curseforge and the addon. I think similar to DBM and BigWigs, RCLootCouncil is a popular addon and deserve a discord server. Thanks.

Upon login getting warning that my version 2.1.10 is out of date, and that the latest version is 2.1.8.

I'm debating whether v2.0 should be pushed to the current project on Curse, or if it would be better to create a new project called "RCLootCouncil2".

Logistically it's better to use the same project (we could code around people using an older version), but otherwise a new project makes more sense.

You did not specify a license. It's common, but I like to be extra careful for those things.

So, can I fork this and whack away? I want to check out adding a module to it.

TLDR,

• personal loot is the ONLY loot method in BFA. There is no way to change to another loot method in BFA. No more guild master loot.
• The eligibility to trade the item is simple: If you have already owned a soulbound item on the same slot with equal or higher item level, the item looted by you will be tradable.

http://www.wowhead.com/news=283905/liveblog-of-the-april-26-battle-for-azeroth-beta-q-a-with-ion-hazzikostas

Highlights

Here are some highlights of the Q&A:

• Charge, Disengage and Infernal Strike will be removed from the GCD in a future build.
• Azerite Power is now called Artifact Power
• Conquest Gear will still have random rewards, but also a structure that will award pieces at set timetables.
• Personal loot will be used for all of BFA.

Any updates regarding loot methods in BFA?

Personal loot has really been the default choice in Legion. The only place where it's not is Guild Groups in raiding content. The choice was not meant to curb split raiding. The advantages are it has is more consistency over the entire game and it adds something personal. Group and Master Loot makes you the mercy at others. When you kill a boss, the reward is disconnected and you deserve the loot. Trading will allow for the social structures to do some things with loot.

How will the item level and trading restriction for Personal Loot work mechanically going forward?

The highest item level piece in that slot that you have looted and soulbound will be recorded. You can trade anything up to and including that item level.

https://www.mmo-champion.com/content/7554-Developer-Q-A-with-Ion-Hazzikostas-Battle-for-Azeroth

Loot Methods

• Personal Loot has been the default in WoW for some time now. All of dungeons, PvP, the outdoor world are all personal loot.
• The only place other loot methods are used are in guild raids.
• This change wasn't made to stop high end split raids. That's something the team wants to do, but that wasn't the point of this change.
• There is more personal agency and control as an individual of your fate.
• There are some guilds that have awarded loot well for many years.
• Group and Master Loot puts players at the mercy of others, often in ways that aren't fair.
• Trial players in a new guild may not get anything for weeks because that is the guild policy.
• When you kill a boss, it isn't about if there is something on the corpse that you want, but if someone is going to give you that loot. It disconnects the reward from killing the boss.
• You deserve the loot for killing the boss.
• It's not called Personal Loot anymore, it's just Loot. This is how loot works in the entire game.
• Trading restrictions for loot will work the same as they do now for the most part. If it is lower than the highest item level piece you have ever looted and had soulbound for that slot, you can trade it.

Another addon called Mizus Raidtracker blocks RCLootCouncil from opening the history window. Typing /rc history simply does nothing, neither does clicking the "Open the Loot History" button in the addon options.

There are no LUA errors for this. It only happens if RCLootCouncil and MRT are both enabled. Somehow they are interfering.

I've also listed the issue on MRT's page here: https://wow.curseforge.com/projects/mizusraidtracker/issues/74

It is now confirmed that master loot is gone in BFA

Can you help me to figure out the usage of the event ENCOUNTER_LOOT_RECEIVED?
What I already known is that this event fires in personal loot, so other people can know what has dropped. Though the game does not show the loot banner in the interface if the loot is done late, it does not mean this event is not fired. Read the code at the bottom for more details.

Return value for "ENCOUNTER_LOOT_RECEIVED":
encounterID, itemID, itemLink, quantity, playerName, className

My current plan to use this event:

1. All items returned by "ENCOUNTER_LOOT_RECEIVED" will be added to the session frame.
2. The group leader will wait for several seconds for RC addon message after "ENCOUNTER_LOOT_RECEIVED" to determine whether the item is tradable. During this time, the session cannot be started.
3. Item not trabable will still be added to the lootTable/votingframe, to give council a complete view what has dropped. Should give an option for this.

Can you help me to figure out the following? I will test it myself in LFR when I get time.

1. Does ENCOUNTER_LOOT_RECEIVED fire if loot is done a while after boss's death (~30s)?
2. Does it fire if loot is done after the next boss is dead?
3. Does it fire for other player if other player is in the different wing in the instance?
4. The time difference between ITEM_PUSH and ENCOUNTER_LOOT_RECEIVED. And which one fires first.

// FrameXML/LevelUpDisplay.lua
function BossBanner_OnEvent(self, event, ...)
	if ( event == "BOSS_KILL" ) then
		wipe(self.pendingLoot);
		local encounterID, name = ...;
		TopBannerManager_Show(self, { encounterID = encounterID, name = name, mode = "KILL" });
	elseif ( event == "ENCOUNTER_LOOT_RECEIVED" ) then
		local encounterID, itemID, itemLink, quantity, playerName, className = ...;
		local _, instanceType = GetInstanceInfo();
		if ( encounterID == self.encounterID and (instanceType == "party" or instanceType == "raid") ) then
			-- add loot to pending list
			local data = { itemID = itemID, quantity = quantity, playerName = playerName, className = className, itemLink = itemLink };
			tinsert(self.pendingLoot, data);
			-- check state
			if ( self.animState == BB_STATE_LOOT_INSERT and self.lootShown < BB_MAX_LOOT ) then
				-- show it now
				BossBanner_SetAnimState(self, BB_STATE_LOOT_EXPAND);
			elseif ( not self.animState and self.lootShown == 0 ) then
				-- banner is not displaying and have not done loot for this encounter yet
				-- TODO: animate in kill banner
				TopBannerManager_Show(self, { encounterID = encounterID, name = nil, mode = "LOOT" });
			end		
		end
	end
end

This is probably for v2.9.

1. As a ML, I want to see if a raid member has collected an appearance so I can easily distribute an item that everyone has passed.
2. The only technical issue is that how I can know if the appearance is collected when the item is a set token. There is no API to relate the tier token to the appearance. Some data is needed in the LUA file, but it is hard to export this data without lots of manual work.
3. For non-token, such info can be easily retrieved by tooltip parsing.

According to the developer liveblog on March 15, the Game Director Ion Hazzikostas talks about the possibility of the retirement of Master Loot

Will personal loot be the only option for current-level raids?

It's a reasonable expectation. There's a higher total loot count on personal, and the reason that people currently doing Master Loot is for tier sets which don't exist in BFA.

Though it's definitely not a final decision, as eliminating the option to Master Loot has lots of side effects, I think more work should be done towards the personal loot.
I think the essential features to make the addon work properly in the personal loot.

1. Automatic RC session popup when corpse is looted by raiders in personal loot mode.
2. Loot history should record the origin owner of the item, and should update automatically when traded (Even if trade to someone who is not the winner in a RCLootCouncil session)
3. A trade frame to show the information who should be traded and what item should be traded, an easy button to initiate the trade if people are close enough, etc.