Support for Savage Defense issues

92 Blood Elf Death Knight
10250
Hey Charsi, check it. I found one from your guild. I'm going to add commentary to this thing.

[19:54:38.768] Cleoboltra Echo of Light Umanikeru +0 (O: 1432)
[19:54:39.011] Cleoboltra Renew Umanikeru +0 (O: 3285)
// Max Health

[19:54:39.111] Cho'gall hits Umanikeru 55067 (A: 30284)
[19:54:39.281] Umanikeru's Blood Shield fades from Umanikeru (Remaining: 0)
[19:54:39.791] Cho'gall Unleashed Shadows Umanikeru 31126 (R: 23995)
[19:54:40.963] Cho'gall hits Umanikeru 69101
// Net damage: 155294
[19:54:41.180] Zienth Rejuvenation Umanikeru +4137
[19:54:41.242] Umanikeru Rune Tap Umanikeru +19575
[19:54:41.507] Cleoboltra Renew Umanikeru +*4929*
[19:54:41.757] Ggx Holy Radiance Umanikeru +*204*
[19:54:42.178] Ggx Holy Radiance Umanikeru +*204*
[19:54:42.521] Umanikeru gains Blood Shield from Umanikeru (Remaining: 60823)
[19:54:42.521] Cleoboltra Greater Heal Umanikeru +28434
// +57843
[19:54:42.537] Cho'gall Unleashed Shadows Umanikeru 46883 (R: 6024)
[19:54:42.552] Umanikeru Death Strike Umanikeru +36008
[19:54:42.552] Cleoboltra Circle of Healing Umanikeru +6561
// Net damage: 101765
[19:54:42.713] Cho'gall hits Umanikeru 27804 (A: 60823)
[19:54:42.982] Umanikeru's Blood Shield fades from Umanikeru (Remaining: 0)
[19:54:43.878] Cleoboltra Renew Umanikeru +3680
[19:54:44.320] Cleoboltra Echo of Light Umanikeru +172
// Net damage: 125717
[19:54:44.565] Cho'gall hits Umanikeru 69674 (O: 1234)
/**
* Suggests a total HP of 195391; Has overkill of 1234 for 196625 net damage.
* The DK stays alive; suggesting an error in timing OR that the shield is actually
* stopping the damage.
*/

[19:54:44.895] Umanikeru gains Blood Shield from Umanikeru (Remaining: 74443)
[19:54:44.895] Umanikeru's Blood Shield is refreshed by Umanikeru (Remaining: 3535)

// Blood shield takes a hit of 70908; the full strike, including overkill

[19:54:44.939] Umanikeru Death Strike Umanikeru +44072
[19:54:45.438] Cleoboltra Echo of Light Umanikeru +172
[19:54:45.798] Cruisecho Holy Radiance Umanikeru +*181*
[19:54:46.124] Corrupting Adherent Corrupting Crash Umanikeru 51974 (R: 15025)
// Net w/ shield: 133266
// Net w/out shield: 204174

[19:54:46.140] Cruisecho Holy Radiance Umanikeru +*326*
[19:54:46.236] Cleoboltra Echo of Light Umanikeru +172
[19:54:46.369] Cho'gall hits Umanikeru 51629 (A: 3535)
[19:54:46.416] Cleoboltra Renew Umanikeru +*5520*
[19:54:46.527] Umanikeru's Blood Shield fades from Umanikeru (Remaining: 0)
[19:54:46.655] Cleoboltra Binding Heal Umanikeru +*23341*
[19:54:46.982] Cruisecho Holy Radiance Umanikeru +*351*
[19:54:47.010] Corrupting Adherent Corrupting Crash Umanikeru 39435 (R: 15200)
// Net w/ S: 194620
// Net w/o S: 265528

[19:54:47.420] Cleoboltra Echo of Light Umanikeru +697
[19:54:48.345] Cleoboltra Echo of Light Umanikeru +697
[19:54:49.095] Cleoboltra Renew Umanikeru +3680
[19:54:49.416] Cleoboltra Echo of Light Umanikeru +697
[19:54:49.944] Cho'gall hits Umanikeru 6542 (O: 43852)
// Net w/ S: 195391 ignoring overkill
// Net w/o S: 266299; ignoring overkill

[19:54:50.418] Umanikeru dies

Based on that occurrence, the shield is being applied. It contradicts my log. Now I need to find another log.

http://www.worldoflogs.com/reports/jz8chsanhk5xgfz6/xe/?s=1173&e=1376&x=spell%3D%22Blood+Shield%22+or+%28type%3DTYPE_DEATH+and+targetName%3D%22Umanikeru%22%29+or+%28targetName%3D%22Umanikeru%22+and+%28type%3DTYPE_DAMAGE+or+type+%3D+TYPE_HEAL%29+or+spell%3D%22Guardian+Spirit%22%29&page=2
Edited by Dosvidaniya on 4/5/2011 9:38 AM PDT
Reply Quote
100 Blood Elf Priest
14735
04/04/2011 08:26 PMPosted by Dosvidaniya


On live if druids aren't getting multiple absorbs through latency, but are still suffering the hit pre-absorb reduction from latency bug, then the change on the PTR to allow Savage defense to absorb more than one hit is still a buff. Even though it has the same flaw of losing absorb size through latency to pre-absorb hits.

Or is my tired mind giving me bad logic?

If we operate under the assumption that both are occurring on live as well, then yes. However, I can't find that same glitch on live. Every log I've pulled up, I've found at least 2 occurrences of that bug (in 500 lines of combat) for DKs (even boss tanking). Pulling up a random live druid, I can't find any. The closest thing I can find looks like this (random log, one of the last ten posted).

[21:12:08.256] Nupraptor's Savage Defense fades from Nupraptor
[21:12:09.692] Onyxia hits Nupraptor Absorb (21044)
[21:12:09.911] Nupraptor gains Savage Defense from Nupraptor
[21:12:09.911] Nupraptor's Savage Defense fades from Nupraptor
[21:12:11.295] Onyxia hits Nupraptor Absorb (19224)
[21:12:12.664] Onyxia hits Nupraptor 18458 (A: 5912)
[21:12:14.228] Onyxia hits Nupraptor 6250 (A: 18115)

There isn't a way to tell which is SD on live; however, there are absorbs there. Another occurrence has an absorb, then a gain, then a diminish. I don't think the starting bug exists on live for druids.


Wow, I must've been out of it when I posted that. Druids on live can't suffer this precise issue because live SD is one-hit. If the pre-absorb bug were present on live in any form, it would just be removing SD procs due to pre-proc hits.

Apologies.
Reply Quote
90 Worgen Druid
12790
Wow, I must've been out of it when I posted that. Druids on live can't suffer this precise issue because live SD is one-hit. If the pre-absorb bug were present on live in any form, it would just be removing SD procs due to pre-proc hits.

Apologies.

What? Every savage defense mishap in the PTR logs happens on live:

[23:55:56.808] Sinestra hits Reesi 46166
[23:55:57.115] Reesi gains Savage Defense from Reesi
[23:55:57.115] Reesi's Savage Defense fades from Reesi
[23:55:58.611] Sinestra hits Reesi 51690

__

[23:58:21.676] (X)Twilight Drake hits Reesi 40676
[23:58:23.569] Twilight Drake hits Reesi 43215
[23:58:23.573] Reesi gains Savage Defense from Reesi
[23:58:23.672] Reesi's Savage Defense fades from Reesi

__

[00:00:28.775] Reesi's Savage Defense is refreshed by Reesi
[00:00:28.833] Twilight Whelp hits Reesi Absorb (6891)
[00:00:29.017] Twilight Whelp hits Reesi Absorb (7469)
[00:00:29.017] Twilight Whelp hits Reesi Absorb (7377)
[00:00:29.142] Reesi's Savage Defense fades from Reesi
Reply Quote
100 Blood Elf Priest
14735
Wow, I must've been out of it when I posted that. Druids on live can't suffer this precise issue because live SD is one-hit. If the pre-absorb bug were present on live in any form, it would just be removing SD procs due to pre-proc hits.

Apologies.

What? Every savage defense mishap in the PTR logs happens on live:


The way I wrote it, and was probably thinking it (though I'm not sure - I was pretty tired), was in the context of absorb/refresh. And live SD can't refresh.

I'm not saying a latency bug can't exist on live. I'm saying I pulled a stupid.
Reply Quote
Community Manager
There are two issues here.

One is that the combat log is saying “refresh” in a confusing way when it’s really just applying damage to the shield (i.e. a new shield has not been created). We’re looking at some ways that might be fixed.

The second issue has to do with our combat log (or third party logs) apparently disagreeing about what happened. Remember, our combat calculations are done on the realm side and then reported to the client, but the client only gets those reports periodically. The message has to travel a potentially long distance between your client and our realms. It’s important that the calculations are done realm-side though, to maintain gameplay integrity.

Because of the latency inherent in client – realm communication, it can appear that a hit lands before the shield procs, yet still applies to the shield, leading to the mistaken impression that the proc isn’t occurring properly. In reality, the server is (probably) performing the steps correctly, but the client sometimes lags behind. For example, there's a case where what actually happened is this sequence: 1) shield proc, 2) hit, 3) absorb, but the client is slightly behind and instead (incorrectly) shows 1) hit, 2) shield proc, 3) absorb in the combat log. Or it could appear that you lost shield points without actually taking less damage, when in reality either the shield or your health pool weren’t affected. Or it could appear that if you take multiple hits nearly simultaneously that the shield did nothing to the later hits, but in reality the shield was gone on the first hit and your client just hasn’t been notified of that fact yet. We will investigate this issue just to make sure, but we’re pretty confident that Savage Defense and Blood Shield are working correctly and are just sometimes getting misreported. With Savage Defense lasting longer in 4.1, you may see this kind of thing more often.

The takeaway is that latency can in some cases cause combat log display issues like the one we’re seeing here. We understand that a lot of you use the combat log as a reporting tool to analyze a fight after the fight has concluded. The combat log as currently implemented is supposed to give you a data feed in real time. We’d like to redesign the combat log to fill that post-combat analysis role better (as Ghostcrawler alluded to in a recent Q&A) but that is a Very Big Task. Just delaying the current combat log so that it was in 100% parity with the server could cause serious issues with third party mods among other things, so we have to be careful not to turn a single screw and end up dismantling the whole machine, so to speak. Despite its limitations, it remains an accurate and useful tool in the vast majority of circumstances.
Reply Quote
85 Draenei Death Knight
7430
TY for the attention and information Daxx.
Reply Quote
90 Tauren Druid
10110
Why not just make Blood Shield and Savage Defense proc off incoming damage and avoid the headache that is client-server lag?
Reply Quote
90 Night Elf Druid
CFT
10670
I had a suspicion this was the case. The differences appeared random enough that they could be caused by network latency.
Reply Quote
100 Human Paladin
16250
I'm not sure which I like more, Informational Dax or Sarcastic/Witty April Fools Dax.

Nevertheless, that was a good read.
Reply Quote
90 Night Elf Druid
CFT
10670
I'm not sure which I like more, Informational Dax or Sarcastic/Witty April Fools Dax.

Nevertheless, that was a good read.

I vote we keep Daxx. Since he seems to be the person that knows what they're talking about.
Reply Quote
85 Draenei Death Knight
7430
I'm not sure which I like more, Informational Dax or Sarcastic/Witty April Fools Dax.

Nevertheless, that was a good read.

I vote we keep Daxx. Since he seems to be the person that knows what they're talking about.


Or at least tries. We <3 u daxx!

Reply Quote
I don't even understand how there can be out-of-order issues to begin with. I'm a professional software engineer and I've developed real-time client-server applications in which in-order sending and retrieval between hundreds of clients was critical. It's never been an issue, even taking into account that our server piece was heavily multithreaded.
Reply Quote
85 Night Elf Druid
8135
04/05/2011 07:06 PMPosted by Tekemay
I don't even understand how there can be out-of-order issues to begin with. I'm a professional software engineer and I've developed real-time client-server applications in which in-order sending and retrieval between hundreds of clients was critical.


Because they don't consider it critical. To them, the value of the client having an accurate combat log is less than the cost of such a system.
Reply Quote
92 Blood Elf Death Knight
10250
04/05/2011 06:29 PMPosted by Daxxarri
We will investigate this issue just to make sure, but we’re pretty confident that Savage Defense and Blood Shield are working correctly and are just sometimes getting misreported. With Savage Defense lasting longer in 4.1, you may see this kind of thing more often.

Much appreciated. Looking at the log from Charsi's guild led me to the conclusion that it is being done correctly server side and that our logs suffer rather than actual abilities.

I appreciate the fact that you took the time to respond to the thread.

We’d like to redesign the combat log to fill that post-combat analysis role better (as Ghostcrawler alluded to in a recent Q&A) but that is a Very Big Task. Just delaying the current combat log so that it was in 100% parity with the server could cause serious issues with third party mods among other things, so we have to be careful not to turn a single screw and end up dismantling the whole machine, so to speak. Despite its limitations, it remains an accurate and useful tool in the vast majority of circumstances.

I understand the restriction. While it would be nice if the combat log were 100% accurate, personally, it isn't worth the overhead in my book. We just weren't sure if the combat log was the source of the issue or if it was an actual bug.
Reply Quote
96 Human Paladin
5285
04/05/2011 06:29 PMPosted by Daxxarri
In reality, the server is (probably) performing the steps correctly, but the client sometimes lags behind.


This was the floating guess on the issue, however...

04/05/2011 06:29 PMPosted by Daxxarri
Or it could appear that you lost shield points without actually taking less damage, when in reality either the shield or your health pool weren’t affected.


Was not entirely known. Does this mean that if a death test were to take place we would not find an overall lose in absorption from hit sniping? You mentioned that you'll do some testing to verify this (tyvm btw) so I assume that it isn't 100% known if it is just a logging bug.
Edited by Fridays on 4/5/2011 7:28 PM PDT
Reply Quote
90 Night Elf Druid
CFT
10670
04/05/2011 07:06 PMPosted by Tekemay
I don't even understand how there can be out-of-order issues to begin with. I'm a professional software engineer and I've developed real-time client-server applications in which in-order sending and retrieval between hundreds of clients was critical. It's never been an issue, even taking into account that our server piece was heavily multithreaded.

UDP is not TCP. I'm willing to bet this stuff is transmitted via UDP, which doesn't have the same messaging structure that TCP does. UDP doesn't care about order. It cares about speed.
Reply Quote
85 Night Elf Warrior
10285
04/05/2011 06:29 PMPosted by Daxxarri
We will investigate this issue just to make sure, but we’re pretty confident that Savage Defense and Blood Shield are working correctly and are just sometimes getting misreported. With Savage Defense lasting longer in 4.1, you may see this kind of thing more often.


Just the fact that you read it and will check is heartening. Thank you.
Reply Quote
85 Draenei Priest
9095
The takeaway is that latency can in some cases cause combat log display issues like the one we’re seeing here. We understand that a lot of you use the combat log as a reporting tool to analyze a fight after the fight has concluded. The combat log as currently implemented is supposed to give you a data feed in real time. We’d like to redesign the combat log to fill that post-combat analysis role better (as Ghostcrawler alluded to in a recent Q&A) but that is a Very Big Task. Just delaying the current combat log so that it was in 100% parity with the server could cause serious issues with third party mods among other things, so we have to be careful not to turn a single screw and end up dismantling the whole machine, so to speak. Despite its limitations, it remains an accurate and useful tool in the vast majority of circumstances.

Most moderate to hardcore guilds would probably still use third-party tools like Archerus, Recount/Skada, Various Threat Analysis tools, and World of Logs. Especially world of logs.

The only way I could see this as being useful is that after a boss encounter, you can download a more accurate, fuller, latency-free copy of the log and then parse it, or it could even be parsed in a world-of-logs like manner on the server, and displayed on a website (with guilds controlling who can see it).

Rule #1 of Software Engineering: Never program something that's already been done unless you can do it cheaper and better.

World of Logs, Recount, etc all are free and all rely on data from the client. Perhaps it would you be your best bet to integrate with these (by providing more detailed log information at the request of a client API at the end of the fight) rather than compete with them. Or even having your servers post directly to world of logs (obviously there would be some agreement you'd have to work out). Database driven web applications are quite common, I hear web mashups are the new things. (And not to mention, you included Wowhead and Wowpedia.org [and not wowwiki - you're paying attention! - wowwiki has been turned into spam now and I think the domain will just be let to expire unless wikia really insists on keeping it whilst the original admins randomly delete topics - this makes me really happy since some people still think wowwiki is a reliable source ])

Edit: Thank you for looking into the issue. I'm actually really glad you finally put absorbs into the combat log (and not just through guessed absorbs). It was sometimes disappointing getting kicked or yelled at or just having awkward moments when doing certain fights as a shield-spammer (LK25, VoA25 frost boss) or just doing very little actual "healing" - I'm sure people who managed to get the epic healer mace were happy as well. I like having accurate numbers available. I hope there's no an issue with Blood Shield/Savage Defense (my DK is almost geared enough for heroics, will be nice to tank and have a 3rd character), and it's just the combat log.
Edited by Mystina on 4/5/2011 7:58 PM PDT
Reply Quote
85 Draenei Priest
9095
I don't even understand how there can be out-of-order issues to begin with. I'm a professional software engineer and I've developed real-time client-server applications in which in-order sending and retrieval between hundreds of clients was critical. It's never been an issue, even taking into account that our server piece was heavily multithreaded.

UDP is not TCP. I'm willing to bet this stuff is transmitted via UDP, which doesn't have the same messaging structure that TCP does. UDP doesn't care about order. It cares about speed.

Don't they have timestamps on them though? (at least, internally?)
Edited by Mystina on 4/5/2011 8:02 PM PDT
Reply Quote
90 Night Elf Druid
CFT
10670
04/05/2011 08:01 PMPosted by Mystina

UDP is not TCP. I'm willing to bet this stuff is transmitted via UDP, which doesn't have the same messaging structure that TCP does. UDP doesn't care about order. It cares about speed.

Don't they have timestamps on them though?

UDP packets aren't reassembelled in the order they are sent. They are assembelled in the order they are received.

Unlike TCP, which is reassembelled in the order they are sent.
Reply Quote

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Forums Code of Conduct

Report Post # written by

Reason
Explain (256 characters max)
Submit Cancel

Reported!

[Close]