[BUG] Voting frame broken due to player leaving?

[christiansegercrantz]

Describe the bug I would love to give a

A clear and concise description of what the bug is.

but I won't be able to. What I think happened was that that I was one of our raiders left mid raid and he had been assigned loot, was assigned loot as he was leaving or as he had already left. Anyhow, after that the voting frame didn't show properly stuff. Wrong rolls, icons and order for people and what not. It is essentially impossible to make use of the addon in that state. This also happened the raid after this 4 days later when the raider was not even in the group.

To Reproduce Honestly no clue. Currently it happens all the time for me and I don't know how to get rid of it.

Expected behavior The voting frame should work like normally.

Error message I had probably 500 of these, everytime I swapped item I got a new one. Van try to get more, there's a couple of different ones but this is the one I saw the most

Lua error

From bugsack: ``` 983x RCLootCouncil/Modules/votingFrame.lua:1487: attempt to index field '?' (a nil value) [string "@RCLootCouncil/Modules/votingFrame.lua"]:1487: in function `fnDoCellUpdate' [string "@RCLootCouncil/Libs/lib-st/Core.lua"]:849: in function `Refresh' [string "@RCLootCouncil/Modules/votingFrame.lua"]:966: in function `updateFunction' [string "@Blizzard_SharedXML/SecureScrollTemplates.lua"]:232: in function `FauxScrollFrame_OnVerticalScroll' [string "@RCLootCouncil/Modules/votingFrame.lua"]:966: in function `SwitchSession' [string "@RCLootCouncil/Modules/votingFrame.lua"]:1368: in function Locals: rowFrame = ScrollTable1Row3 { PixelSnapDisabled = true highlight = Texture { } cols = { } } frame = ScrollTable1Row3col2 { text = ScrollTable1Row3col2text { } } data = { 1 = { } 2 = { } 3 = { } 4 = { } 5 = { } 6 = { } 7 = { } 8 = { } 9 = { } 10 = { } 11 = { } 12 = { } 13 = { } 14 = { } 15 = { } 16 = { } 17 = { } 18 = { } 19 = { } 20 = { } 21 = { } 22 = { } 23 = { } 24 = { } 25 = { } 26 = { } 27 = { } 28 = { } 29 = { } 30 = { } } cols = { 1 = { } 2 = { } 3 = { } 4 = { } 5 = { } 6 = { } 7 = { } 8 = { } 9 = { } 10 = { } 11 = { } 12 = { } 13 = { } } row = 3 realrow = 3 column = 2 fShow = true table = { sorttable = { } filtered = { } cols = { } scrollframe = ScrollTable1ScrollFrame { } offset = 0 showing = true DefaultEvents = { } rows = { } data = { } fSelect = true multiselection = false rowHeight = 20 displayRows = 15 defaulthighlightblank = { } defaulthighlight = { } head = ScrollTable1Head { } events = { } frame = ScrollTable1 { } } name = "Kofotsjonas-Kazzak" (*temporary) = { defaults = { } modules = { } debug = false classTagNameToID = { } PREFIXES = { } db = { } OPT_MORE_BUTTONS_VALUES = { } classIDToDisplayName = { } testMode = false nnp = false name = "RCLootCouncil" C_Container = { } VER_CHECK_CODES = { } INVTYPE_Slots = { } defaultModuleState = false handleLoot = true Utils = { } ItemStorage = { } EJLatestInstanceID = 1273 TradeUI = { } Sync = { } playerClass = "SHAMAN" coreEvents = { } recentReconnectRequest = false nonTradeables = { } BTN_SLOTS = { } lootGUIDToIgnore = { } player = { } masterLooter = { } hooks = { } isMasterLooter = true classDisplayNameToID = { } autoGroupLootWarningShown = false isInGuildGroup = true currentInstanceName = "Nerub-ar Palace-Heroic" UI = { } CATALYST_ITEMS = { } guildName = "Baboon Platoon" guildRank = "Main" mldb = { } baseName = "RCLootCouncil" enabled = true tooltip = RCLootCouncil_TooltipEventHandler { } lastEncounterID = 2921 bossName = "The Silken Court" hasReceivedCouncil = true playersData = { } optionsFrame = Frame { } lootMethod = "personalloot" playerName = "Doccool-Kazzak" candidatesInGroup = { } realmName = "Kazzak" mlChatCmdHelp = { } CLASS_TO_ATLAS = { } isCouncil = true customChatCmd = { } classIDToFileName = { } enabledState = true MIN_LOOT_THRESHOLD = 3 classTagNameToDisplayName = { } responses = { } lootDB = { } blackListOverride = { } blacklistedItemClasses = { } chatCmdHelp = { } lootSlotInfo = { } lootOpen = false inCombat = false defaultModuleLibraries = { } Log = { } version = "3.14.1" orderedModules = { } LOGO_LOCATION = "Interface\AddOns\RCLootCouncil\Media\rc_banner" Compat = { } RESPONSE_CODE_GENERATORS = { } ModuleData = { } PROFILE_EXPORT_IDENTIFIER = "RCLootCouncilProfile" } (*temporary) = nil (*temporary) = 39 (*temporary) = "Kofotsjonas" (*temporary) = "Kofotsjonas" (*temporary) = "Kofotsjonas-Kazzak" (*temporary) = "attempt to index field '?' (a nil value)" addon = { defaults = { } modules = { } debug = false classTagNameToID = { } PREFIXES = { } db = { ```

Saved Variables RCLootCouncil.lua.zip.zip

evil-morfar commented 2 days ago

I'm aware of this issue - you can avoid it by finishing a session before adding new items.

It happens because a player is present when you start a session, but not for the "next" session that you add on top of the first, thus creating issues. It's not an easy thing to fix, so I'd advice you not extend the sessions, i.e. award all items or click "Abort".

This also happened the raid after this 4 days later when the raider was not even in the group.

Not entirely sure about this, your log doesn't show it.

christiansegercrantz commented 1 day ago

Thanks for the quick answer. This is odd, since we have had the same session throughout the whole raid with people swapping chars without problems. This seems to be triggered by something specific, but I'm not sure. Especially since the name of the previous raider was still showing up in errors days later. I wonder if I didn't ever actually abort the session between the two raid days and that could've caused the problem.

Is there some other data I can provide you that could show you the behaviour? We can go into a legacy raid or the normal raid and see if the problem is still occurring.

Regarding the proposed solution, our use case is mainly that to clear the bosses which are on farm (can be hc+mythic even) and then give out all the loot. Is it so that the add-on is not intended for/does not support this kind of behaviour but is intended to share the loot as soon as it is awarded. (Not that we do not want to award all the loot at the end of the raid, but award as we go and reward items later if say a better items drop. Awarding all the items at the end takes unnecessary time compared to awarding during trash clear and doing minor tweaking at the end of the raid/before prog).

evil-morfar commented 1 day ago

I haven't done a deep dive into it yet, but my initial analysis confirmed it can (but won't always) happen when extending sessions. It depends a lot on what you do. The only unusual thing about your log is the shear amount of errors, but again it depends on usage, and I'm not seeing anything I don't except from this issue.

The error itself is quite generic, and can be triggered by other things, as it's basically just a "I can't display what you want me to" error - but everything points at people leaving between sessions. At this time I can't distinguish between this and other potential issues though.

I imagine you just saw old errors in the bugtracker, as sessions don't persist between relogs or even reloads. If you're in anyway able to reproduce it, without extending sessions, I'd very much like to know.

I didn't intent for it to be used this way when creating it, but since it's possible it should also be supported - you're not the only one doing so, although the majority of people I get in contact with ends up doing it by mistake.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[evil-morfar]

I'm aware of this issue - you can avoid it by finishing a session before adding new items.

It happens because a player is present when you start a session, but not for the "next" session that you add on top of the first, thus creating issues. It's not an easy thing to fix, so I'd advice you not extend the sessions, i.e. award all items or click "Abort".

This also happened the raid after this 4 days later when the raider was not even in the group.

Not entirely sure about this, your log doesn't show it.

[christiansegercrantz]

Thanks for the quick answer. This is odd, since we have had the same session throughout the whole raid with people swapping chars without problems. This seems to be triggered by something specific, but I'm not sure. Especially since the name of the previous raider was still showing up in errors days later. I wonder if I didn't ever actually abort the session between the two raid days and that could've caused the problem.

Is there some other data I can provide you that could show you the behaviour? We can go into a legacy raid or the normal raid and see if the problem is still occurring.

Regarding the proposed solution, our use case is mainly that to clear the bosses which are on farm (can be hc+mythic even) and then give out all the loot. Is it so that the add-on is not intended for/does not support this kind of behaviour but is intended to share the loot as soon as it is awarded. (Not that we do not want to award all the loot at the end of the raid, but award as we go and reward items later if say a better items drop. Awarding all the items at the end takes unnecessary time compared to awarding during trash clear and doing minor tweaking at the end of the raid/before prog).

[evil-morfar]

I haven't done a deep dive into it yet, but my initial analysis confirmed it can (but won't always) happen when extending sessions. It depends a lot on what you do. The only unusual thing about your log is the shear amount of errors, but again it depends on usage, and I'm not seeing anything I don't except from this issue.

The error itself is quite generic, and can be triggered by other things, as it's basically just a "I can't display what you want me to" error - but everything points at people leaving between sessions. At this time I can't distinguish between this and other potential issues though.

I imagine you just saw old errors in the bugtracker, as sessions don't persist between relogs or even reloads. If you're in anyway able to reproduce it, without extending sessions, I'd very much like to know.

I didn't intent for it to be used this way when creating it, but since it's possible it should also be supported - you're not the only one doing so, although the majority of people I get in contact with ends up doing it by mistake.