question: Did you use the latest alpha ... ?

Removing that part you said, will make the mod crash your attempt completely! It would set the same icon on 5 targets = failure


At the moment we scan for these events:
SPELL_AURA_APPLIED (normal event if a debuff is applied)
SPELL_AURA_REFRESHED (if he casts it before old 1 expires (in combatlog) and you already had PC debuf)
SPELL_MISSED (you resisted it, but you are put in the table. Your icon should be cleared just after the mod gave you 1)


This should cover the resisting part



It kinda comes down to this: (its a bit more complex, as we remove icons on ppl who resisted etc)

i have no doubt that 4473 or higher should work without issue on fight. 4492 also updates that mod but all that did was remove the phase 3 health removal code (in anticipation of blizzard removing that kind of functionality in 4.0 from mods)

Our raidleader(killeress) is using the r4486 DBM,but also failed this week,last week looks ok because we have no person resist=.=

I have delivered our combatlog to you,but no chatlog loged...

And i m sorry for that i didnt update my dbm,and i see the old code.Our Rl has gave me a r4486 DBM,i have seen it.

I still think is not enough 5 person has debuff case this problem.

if we just scan our raid debuff and put them into a table,then mark the person in the table,after the debuff time,we clear the table,and againI m not quite know about LUA language,i m just thinking from C,maybe not right)

resists should be added to table now though.

i see.

so your idea is add all person(include resist)to a table,mark them,and then remove the resist person.

i m just thinking whether we should go to testing the debuff on anubarak,and makes more logs= =

indeed that is what we do atm. Add all ppl who got (or should have gotten) the debuff to 1 table and add all resists to a 2nd table
When the first table is "full" (5 targets) it sets icons on all 5. Once the icons are set, the icons are removed from the ppl in the 2nd table.

you have a log from this week? the version you had this week shoulda worked with spell_miss, maybe something else went wrong this week?

we have combatlog,but our rl miss chatlog.

i have already delivered it to Arta.

we can sure that the mark is still wrong.

checked the log and couldnt find where it could have gone wrong

after each SPELL_CAST_SUCCESS event, there was always a combination of 5 events that looked like this

SPELL_CAST_SUCCESS
SPELL_MISSED or SPELL_AURA_APPLIED
SPELL_AURA_APPLIED
SPELL_AURA_APPLIED
SPELL_AURA_APPLIED
SPELL_AURA_APPLIED

Oh,i gotta some difference.
this week
SPELL_MISSED,0xF130008704000A03,"阿努巴拉克",0xa48,0x0200000000398D14,"乂天下無雙乂",0x514,68510,"透骨之寒",0x10,IMMUNE

last
SPELL_MISSED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x020000000034C69C,"卑詩小櫻桃",0x514,68510,"透骨之寒",0x10,MISS(from forms)

one is immune, one is miss.

both still use the same event (SPELL_MISSED) and both have the same spellId (68510)

the extra argument at the end (missType) is not used in anyway and does not affect the code

how is it going?

nothins been changed, it should be fixed, if it's still not something else is wrong, there's just no reason the code shouldn't work anymore.

The only thing we could add back in, is that we mark people as soon as they get the debuff. However the icons will NOT be sorted groupwise.

codewise it would be something like this:

are you on chinese 3.2.2 wow by chance? if so that'd explain everything. GUID on 3.2.2 CN wow is 7, 10, not 9, 12, with the improper guid combat detection would not work right causing the table not to wipe on combat start. if table is not empty on a fresh pull Pcold would be a diaster after that.

beyond that. i'm gonna need at least one other person to even confirm it's still broken before anything else is done. cause thousands use dbm, and only ONE person is reporting problems with this encounter (2nd person from same raid verifying there were no icons isn't a 2nd report, when the first person is still only one doing icons). there should be at least 2-3 people in raid running latest alpha to make sure icons get set. this rules out computer and user error more effectively. /dbm version should be run to verify in interface that people actually have the alpha installed properly. announce to chat with chat logging is also something to go with combat log just to see what icons are actually placed and when and how they line up with combat log. there is just apsolutely no reason it shouldn't be working, unless you are in fact on CN wow then the alpha you used last week would not have had proper pull/wipe detection.

EDIT, hmm, anub doesn't use combat pull detection it uses a yell. well then, i have to ask this then, does dbm say anub arak engaged when he's pulled? chatlog pull anyways to make sure the correct local is present for the pull as well as telling us what local you play on.

I have no desire to remove sorting. same code is used on festergut and sindragosa and it doesn't break on them cause those debuffs don't miss. So fixing miss in alpha shoulda fixed the problem.

Quoted from ""azurewind""

Oh,i gotta some difference.
this week
SPELL_MISSED,0xF130008704000A03,"阿努巴拉克",0xa48,0x0200000000398D14,"乂天下無雙乂",0x514,68510,"透骨之寒",0x10,IMMUNE

last
SPELL_MISSED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x020000000034C69C,"卑詩小櫻桃",0x514,68510,"透骨之寒",0x10,MISS(from forms)

one is immune, one is miss.

while on topic of GUID.

why is it different this week? hmm

Quoted from ""Omega""

Quoted from ""azurewind""

Oh,i gotta some difference.
this week
SPELL_MISSED,0xF130008704000A03,"阿努巴拉克",0xa48,0x0200000000398D14,"乂天下無雙乂",0x514,68510,"透骨之寒",0x10,IMMUNE

last
SPELL_MISSED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x020000000034C69C,"卑詩小櫻桃",0x514,68510,"透骨之寒",0x10,MISS(from forms)

one is immune, one is miss.

while on topic of GUID.

why is it different this week? hmm

Its normal that there is a different GUID. Every GUID follows a certain pattern of how it is build

0xAABCCCDDDDEEEEE

where:
AA = unknown.
B = unit type, mask with 0x7 to get: 0 for players, 1 for world objects, 3 for NPCs, 4 for permanent pets, 5 for vehicles.
CCC = If the unit is a pet, CCCDDDD forms a unique ID for the pet based on creation order; if a world object, CCCDDDD is the object ID; otherwise unknown.
DDDD = If the unit is an NPC, this is the hexadecimal representation of the NPC id.
EEEEEE = If the unit is a player, this is a unique identifier based on creation order. Otherwise, this is a spawn counter based on spawn order.

Each time a NPC respawns after he died/despawned, he will have a different GUID (as the "EEEEE" part is changed)


Looking at both GUIDs
So last week there were lesser wipes/killes before they attempted/killed him

We are not in Chinese 3.2.2,Anub is not opening now in 3.2.2,we are in Taiwan 3.3.5.From the combatlog "透骨之寒" you can see,its Traditional Chinese.
Though many people are using DBM,but few of them are still fighting anub,is it right?and only when heals using the icon method to heal Penetrating Cold can cause this problem,and just even they die some people in Anub,if they dont trying the achievement of insame,they still can kill Anub and they dont care about this.
We will record both combatlog and chatlog this week,and as we all known,there is no much time for us to try= =.
Wish we have a good luck.

try 4509. I don't really like having a backup scheduler cause any hickup in fps, or latency can cause the entire point of the sorting to fail. in fact i'll commit a 4510 with an extra long wait for backup schedule though, a full second should do it.

EDIT:
increase wait to a full 1 second. i don't want icons to get screwed up by computer/server lag. which was the whole reason the scheduler was removed in first place. only takes ONE lagging person running 1fps or 250ms+ to pick up 1 late icon and cause of how sorting works, will set icons on different targets than first person did and mess up all the icons anyways.

to give an example of what's gonna be broken now

i'll use your example but edited

9/6 23:44:22.420 SPELL_CAST_SUCCESS,0xF13000870400050C,"阿努巴拉克",0x10a48,0x0000000000000000,nil,0x80000000,68510,"透骨之寒",0x10
9/6 23:44:22.420 SPELL_MISSED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x020000000034C69C,"卑詩小櫻桃",0x514,68510,"透骨之寒",0x10,MISS
9/6 23:44:22.490 SPELL_AURA_APPLIED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x0200000000358DD1,"Whip",0x514,68510,"透骨之寒",0x10,DEBUFF
9/6 23:44:22.490 SPELL_AURA_APPLIED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x0200000000BB8F98,"靜靜輕輕的听",0x514,68510,"透骨之寒",0x10,DEBUFF
9/6 23:44:22.490 SPELL_AURA_APPLIED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x0200000000B754A5,"Jalan",0x514,68510,"透骨之寒",0x10,DEBUFF
--oops lag spike
schedule went off, set icons on 3 targets (the missed didn't break it since scheduler avoids that, BUT)
9/6 23:44:23.490 SPELL_AURA_APPLIED,0xF13000870400050C,"阿努巴拉克",0x10a48,0x02000000000F0761,"Hidi",0x512,68510,"透骨之寒",0x10,DEBUFF
here is another person that arrived AFTER scheduled marking already set icons. a new method is scheduled, skull is REMOVED from who it was on above and now set on Hidi.
now you still got 1 person without an icon that's gonna die and ruin achievement. now the somewhat new latency check should minimize how often this happens, the person would have to spike at the exact moment of icon, cause someone who has a high average will be forbidden from setting icons. but it can and will still happen. also really low fps/crappy system can cause it too and there is no method in dbm to check for this, your client locks up for a second and gets an target late will have same result as latency spike.

see the problem now with just scheduling a backup method? this is why the mod was coded to apsolutely set no marks until 5 targets are put out. :\ lags happen just as often as misses so really it's trading one issue for another. only 100% way shoulda been setting icons on everyone, including miss, that should have worked. code wise that was only flawless method but either you didn't have right alpha when you tried it, or something is goofy on your end. But i changed back to scheduler method anyways only in thought of cataclysm 85s doing the encounter with smaller size raids so because of that this method will be prefered way to do it soon™.

but any bug reports about icons getting changed after they were set cause someone lagged will be immediately closed just saying so now. (cause we've gotten them).