Since the update half our raid says they cannot see any broadcasts/any dkp. As well as our officer who has people with double the DKP they should have, and no amount of deleting is fixing anything.

Please post your saved variables file if it has compete data

If you don't have one and can get have your officer give you his to post here I should be able to remigrate it and take care of duplicate data

What type of file can I post it as, everytime I drag it, it says not supported?

Add a .txt to the end

These are mine, which appear to be working but not syncing with everyones addon, let me try and get my other officers who has people not showing up/ double

Blizzard_Console.lua.bak.txt

Blizzard_Console.lua.txt

Other officer
Blizzard_Console.lua.txt

Blizzard_Console.lua.bak.txt

Also side question, we run two raid groups with your system, is it meant to handle two? our second officer i posted runs the dkp for the 2nd group, which is why we think his is out of wack with ours...

It should be fine with as many raids as you want. It's out of whack because the migration didn't handle it well because I'm guessing you already had some indexes from the last 2.0 release. That or more than one officer migrated tables. I'll need your monolithDKP saved variables file. It's at WTF\Accounts\ACCOUNT_NAME\SavedVariables\MonolithDKP.lua

I think our GM was the one who migrated before anyone else could...

Just mine our both of ours again?

Mine
MonolithDKP.lua.txt

Only one officer should have migrated. Both would be helpful

Seems to be working, just having people all wiping now..

Every officer should replace the file so everyone has the exact same indexes

Yeah we demoted some, and its working for us without them doing the replacement yet, thank you so much for replying timely

No problem. Wanna get this fixed up for as many as I can. The migration was always gonna be a hurdle since most aren't used to this level of participation for an addon. But it didn't go quite as smooth as I had hoped. Once the migration is all handled you shouldn't have to worry about any more file corruption unless an officer decides to just completely destroy your data lol.

Oh, if you demote some while they are online, make sure they relog. The addon determines if they're an officer at login. So even if you demote them out of that officer status, the addon will still think they are until they relog. There are protections on the receiving side as well that would block them. But.. just to be safe.

Also if you happen to have a back up from before the migration that would also help rebuild it for you.

Not sure if our GM backed it up, aside from screen shots before the migration, let me get the other file

No worries. I'm headed home now and will take care if it as soon as I get there

Other officer

MonolithDKP.lua (1).txt

after one member updated he got an error:

Date: 2019-12-11 18:31:13 ID: 1 Error occured in: Global Count: 1 Message: ..\AddOns\MonolithDKP\Modules\comm.lua line 1625: attempt to compare nil with number Debug: MonolithDKP\Modules\comm.lua:1625: ?() ...sic\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:119: ...sic\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:119 [C]: ? ...sic\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:29: ...sic\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:25 ...sic\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:64: Fire() ...ace\AddOns\DBM-Core\Libs\AceComm-3.0\AceComm-3.0.lua:218: OnReceiveMultipartLast() ...ace\AddOns\DBM-Core\Libs\AceComm-3.0\AceComm-3.0.lua:256: ...ace\AddOns\DBM-Core\Libs\AceComm-3.0\AceComm-3.0.lua:246 Locals: None AddOns: Swatter, v8.2.6377 (SwimmingSeadragon) AtlasLootClassic, vv1.4.2 AtlasLootClassicData, vv1.4.2 AtlasLootClassicDungeonsAndRaids, vv1.4.2 AucAdvanced, v8.2.6430 (SwimmingSeadragon) AucFilterBasic, v8.2.6364 (SwimmingSeadragon) AucScanData, v8.2.6365 (SwimmingSeadragon) AucStatHistogram, v8.2.6366 (SwimmingSeadragon) AucStatiLevel, v8.2.6370 (SwimmingSeadragon) AucStatPurchased, v8.2.6367 (SwimmingSeadragon) AucStatSimple, v8.2.6399 (SwimmingSeadragon) AucStatStdDev, v8.2.6369 (SwimmingSeadragon) AucUtilFixAH, v8.2.6371 (SwimmingSeadragon) BagBrother, v Bagnon, v8.2.16 BeanCounter, v8.2.6434 (SwimmingSeadragon) DBMCore, v1.13.24 DBMDefaultSkin, v DBMStatusBarTimers, v Details, v DetailsStreamer, v DetailsTinyThreat, v Enchantrix, v8.2.6428 (SwimmingSeadragon) EnchantrixBarker, v8.2.6469 (SwimmingSeadragon) Informant, v8.2.6374 (SwimmingSeadragon) MonolithDKP, v2.0.6 Pawn, v2.3.11 Questie, v5.3.1 SlideBar, v8.2.6375 (SwimmingSeadragon) Spy, v1.0.18 Stubby, v8.2.6376 (SwimmingSeadragon) WhatsTraining, v1.8.7 ZygorGuidesViewerClassic, v1.0 BlizRuntimeLib_enUS v1.13.3.11303 (ck=488)

^ generated from DKP from line 1625 he said

That can be ignored. It's likely rooted in the corrupted tables. Everyone will be wiping those tables anyway.

Do you guys do everything with the DKP history? Don't do any loot assignments? (There's no loot entries so I just want to make sure it's not missing) And what's the name of the officer you want the migration under?

It seems like the migration was done by Drixa so i just indexed everything in his name. So here's how it works. When you create an entry it creates it with an incrementing index (1 then 2 then 3 etc) and tags the officer that created the entry with their name (So an index looks like Drixa-1 then Drixa-2 etc). If any officer has an index that you do NOT have, they send it to you. That's how the tables got out of whack. Someone had reindexed entries with a different name so they got sent. Here's how you'll avoid that from happening. Take this saved variables file and don't do anything with it yet. Set up a time when you and all the officers can get on together (not just whitelisted officers. Any officer that has "Edit Officer Notes" permissions in guild. Just to be safe). Then have everyone log off and delete their current saved variables file and give them all this one. That will ensure no one has any indexes that could mix with yours. Then just tell all non officers to wipe their tables (in Options tab) and they'll get a resync. You will most likely still see an "Out of date" deal on the status indicator. That's because everyone with bad data is reporting to you that more entries exist than really do. This will sort itself out eventually as everyone gets the bad data wiped.
MonolithDKP.zip

yes we do all -dkp manually and no actual bidding is done aside from whispers,

will work on your fix, and report back

THE one we ARE deleting is the one from account > account name> savedvariables correct?

\WTF\Accounts\ACCOUNT_NAME\SavedVariables\MonolithDKP.lua (and .lua.bak)

Does Drixa, also have to deleted and replace these files?

I'll be releasing a new version soon that will essentially be 2.0 with the old broadcast system with improvements for performance since that one didn't cause so much of a headache. Once that occurs, if you need assistance with data please create a new ticket and I'll be glad to help.