MatsT

I think it's pretty safe to assume that any part that could be used to cheat is determined on the server, to prevent exactly that. This means that:

*The server determines the time of your autoattack hit.
*The server determines if the windfury proc is on cooldown.
*The server determines if the windfury procced.

If any of these is not true, it would be possible to create a clientside hack that allowed for increased dps, in the first case even "infinite" dps. Theoretically blizzard could rely on file integrity checking and The Warden to catch such hacks, as is the case with teleport hacks, but i really doubt it was designed this way.

What the client can determine:
*The client will send your characters position to the server either when it changes or continously.
*The client will send your autoattack status to the server, either when it turns on/off or continously.

This means that as long as you are standing still in melee range with autoattack activated, pretty much nothing is clientside.

The issues that could be creating weirdness is when there is latency involved. One example is when the server calculates the autoattacks and windfury proccs but the results never reach you in time. When you finally receive all the results, what timestamp will they get in the combatlog? Will they get the servers timestamp for when they hit or will they get the timestamp your client received the event result. Another case is when the server receives a signal such as "i turned autoattack on at 12:34:56.789" but it doesn't receive the signal until 10 seconds later. At this point it tries to retroactively calculate all the autoattacks including windfury proccs and such (i think). It will then send the results back to the client. What timestamps is shown on the client in this case?

 

Rouncer

Pretty safe to assume? Leave your assumptions at the door when you are trying to understand how something works because they close your mind to other possibilities.

If everything was simply determined server-side and I am just standing still purely autoattacking why is there a 1-1.2 second delay between the windfury proc and the melee strike that procced it? Why does it take so long for Windfury info to come back if it is all being determined server-side?

Why is there also more of a average delay between the windfury procs from autoattacks then there is from windfury procs from instant attacks?

There is definitely another layer of server-client interaction for determining the windfury procs then merely waiting for the signal to be received. Latency was consistently between 100-140ms for all my testing so why is there only a 200ms delay between the melee crit and UR/Flurry but a 800ms delay before the Windfury proc (that's from looking at the short stormstrike testing)?

As for your anecdotal evidence of latency causing all the "weirdness" do you really think the server accepts timestamps from your client? Do you have any evidence to support that conjecture? Don't you think if it did work that way it would be open to being hacked, where the client could just send false timestamps to the server?

 

Tramana

I believe timestamps in the combatlog are determined clientside. This is why two people running combatlogs don't have matching timestamps for events. It's also why wws has to have sophisticated merging logic that manages drifting clocks. No need for client to send timestamps to the server to get weird latency based combatlogs.

The lag between autoattack and proc could simply be seperate layers of event queues, or even priorities entirely on the server. For example, the latency difference between UR/Flurry and Windfury could be the extra processing that's required for windfury.

autoattack_event -> hit_check -> proc_check -> flurry
//time between autoattack and flurry is the proc_check
vs
autoattack_event -> hit_check -> proc_check -> cooldown_check -> generate 2 new yellow events -> hit_check
// time between autoattack and windfury is the cooldown_check + proc_check + new events + another hit check

The observation that the sub 3.0 interval procs go away when the server isn't busy points to a server side issue, not a network latency issue. On the other hand the difference in delay between autoattack procs and SS procs point to network latency issue. As far as I know, neither observation has much testing behind it yet.

To pinpoint what's going on we need more measurements of attack (auto and special) to windfury proc latency, compared against network and server latency.

A related question: would it be possible to measure server load by looking at the difference between client reported latency, and quartz reported latency? Is there a better way?

 

MatsT

Some assumptions are required in all experiments. The reasons for these assumptions here is that the developers hopefully isn't retarded beyond imagination. If this was not the case it would be possible and not even all that hard for someone with good knowledge of how the network comminucation works and what the packets looks like to give himself a 100% windfury procc rate, or even a 100% crit chance on any attack if that is also clientside.
This i don't know, it's certainly interesting. We should test this more and get some statistics on the delay between hit->UR and hit->wf. Especially in the situations where they procc from the same attack, as we could possibly find a pattern between number of round trips required for each. I'm just speculating here, but one possibility is that the client actively sends the "cast windfury" signal only after it receives the autoattack signal. The UR and flurry on the other hand, does not need to be as synchronized, as the server and the client can independly activate this buff depending on if the attack crit or not. The windfury cast needs to be sent to the server to check if it procced, and then return with the amount of damage done before it can show up in the combat log.

As for the Stormstrike vs autoattack proccs, i can speculate some more. On autoattacks, the server knows that unless you have turned autoattack off, a new autoattack will come exactly your attack speed after the previous attack. It will send the result of said autoattack as soon as it's calculated. The Stormstrike on the other hand, has to be sent from the client when it's cast, and will therefore take a longer time before it's actually calculated on the server. This is somewhat based on my "Anecdotal Evidence". This is based on such situations as when a mob runs towards you and you frost shock it, it somehow teleports back a little bit. Another example is when you cast a spell but nothing happens, then suddenly the spell finishes casting even though you never saw a cast bar. It's very hard to prove exactly how this works and if it's a result of a delay just from the server back to you or both ways.

If we want this discussion to move forward, there's two things we should do. Firstly we should determine how the combatlog timestamps is related to the actual timing. This could for example be done by causing extreme lag or by comparing two combat logs from people with different latency. secondly, i would guess that people who have experience with WoW server software would know more about these things. Someone who have helped creating the "private servers" might be able to help us.

 

Atren

By calculating it on client side you are opening up for cheats and hacks. Sure you can build additional safety procedures, but it quickly would lose point if it was more complicated than actual calculation on server. WF proc is just one random number generation followed by comparison. Cooldown check is another comparison.

On other hand is there need for server to include time stamp for outgoing packet? I am not sure of that.

One possibility is that instead one server doing all those calcs there is more than 1 handling different parts of the game and that is what causing disparancy. Latency is only connection test, calculation and inner communication are not in the latency number. I am not really expert in this field so i can't say how probable that is, but it does sound plausible to me.

 

Rouncer

It could also be something as simple as this.

Server to Client - autoattack from Mainhand weapon hit X for X damage.

Client - Applies damage to X. Notes Windfury Weapon imbue active on Mainhand Weapon.

Client to Server - Windfury Weapon Imbue active on Mainhand Weapon

Server to Client - Windfury Weapon Imbue procced Windfury Attacksx2 for X damage

Client - Applies Windfury Attack damage to X.

 

Andrast

This would require that every single attack has a unique ID because there is a need to associate the proc with the action that caused it. I can't see that being reasonable.

 

◊ Wraithlin

Very easy to test though.
/cast WF, /attack, /unplug internet.

Then have someone else log your combat and see if you score any WF procs after you have disconnected your internet, before you go LD.

 

Rouncer

Let me see if I understand. You are saying to start autoattacking a dummy and then to disconnect your internet since it will continue autoattacking for a little while before you go LD. Then compare combatlogs with someone else who was logging your combat (to make sure that you are only looking at attacks after you disconnected) and see if there were any windfury procs at all.

If that's what you mean it should be done using WF/WF on fast weapons with WF totem to increase the likelihood that the results are relevant since you only get ~10 seconds of autoattacking after you unplug your internet and there can easily be delays that long with only a single imbue of WF.

 

◊ Wraithlin

Yes, that is what I am saying.
If the delay is due to a server/client/server interaction then WF should fail to proc when the client is disconnected. If WF still procs, then the delay is due to how WF is handled internally.

With dagger/dagger 2 imbues, and plenty of hast then 3/4 tests should be sufficient to resolve the question one way or the other.

 

• Caladiera

I can test this tonight if the following will work:

2 computers on my home LAN
2 accounts logging
2 1.3 daggers ([Poniard]) with WF/WF & WF Glyph
1 WF Totem

1) Start autoattack on lvl60 combat dummy
2) WF Proc!
3) FROST SHOCK! (log marker)
4) Unplug ethernet cable
5) Repeat

Potion of Speed?

[e] sequence updated. Thanks.

 

◊ Wraithlin

I would suggest you cast a shock and then pull the lan cable.
You can use the shock to mark when you disconnect in the observers combat log.

What we are looking for is the presence (or absence) of WF procs after the cable is pulled.

 

Rouncer

Try to do it right after a proc since that should put windfury on it's cooldown and since I'm pretty sure you will continue autoattacking for 10 seconds (based on anecdotal evidence from our Feral tank who likes to D/C while tanking and still puts out amazing threat even when D/Ced) which should give us 7 clean seconds for a windfury proc to occur. With fast daggers and the glyph and with the haste you should get a proc within second or two after the cooldown is over anyway.

 

Arvin

I'd have to agree with this, but I'll wait to see what the test shows. Additionally, an easy way to test whether or not WF is tracked by the server or the client is to:

Imbue your weapons with WF.
Disconnect LAN cable.
Click off imbues.
Allow server to log you off.
Log back on and see if your windfury imbues are still active.


I would expect that they are.

 

Boro

I have a combatlog showing Windfury procs after a forced DC. The log is full of other people hitting the dummies but you can filter the clutter. I used an ES as a marker.

Not sure how best to get the log to those that want it but post here and let me know. Size is 128k.

 

• Caladiera

I followed the steps outlined in my previous post using the 2 daggers at the TB lvl60 combat dummies.

It took a while for Cal to DC on the computer Kirayoshi was on (more then 10sec). I saw multiple windfury animations after Cal stopped interactivity on the DCed computer.

Attached Files

	KirayoshiWatchingCombatlog.txt (96.2 KB, 63 views)
	CalActivelyDCedCombatlog.txt (19.0 KB, 36 views)

 

Xoya

I'm not sure if this is at all relevant, but one thing I'd like to bring up is situations with excessive leg and watching to see whether debuffs/buffs that should have worn off actually fall off.

Example: whole server lags, your windfury weapon is about to fall off, but your windfury weapon just sits there pulsing at 0 seconds on your screen until the server updates and tells the client to stop showing the windfury weapon buff.

 

SentinelBorg

This would be a really strange coding. If I as a developer would have to implement something like this, it would work like that:

Server: calculates swing, sends Client the data from the swing, Client shows the swing
Server: looks for wf proc, if procs happens, sends Client the data from the wf hits and starts cooldown, Client shows animation and updates combat log

Everything else would make not much sense. Why increase the communcation and add potential for cheats?
And because the wf proc is a separate event, it is send in its own package, which can be delayed because of lag for some time after the initial swing that procs the windfury.

There are also observations, that support this view:

For example, if there is medium lag, the whole game often stops for a brief moment and then a large pack of events are received at once, sct spams your complete screen and your combat log is full of several actions, that have almost the same timestamp.

 

Rouncer

I agree and the test results from pulling the cable on the internet and looking for a proc support the concept that everything is determined server side but none of it explains why there is such a separation between the melee attack that procs windfury and the windfury proc itself. Some tests had over a second between them. Yet for a proc like Unleashed Rage there is only a 0.2 second delay between the attack that procced the buff and the actual application of the buff. That's the part that is really confusing me and none of what anyone has come up with explains why there is such a variation in the cooldown duration if everything is being determined server side.

 

Atren

Both UR and flurry do not require extra package. If the swing result sent back is crit then you have UR and flurry automatically also. Same applies to any other guaranteed proc at something i bet (like clearcasting and etc). Do not need to send useless information.

 

Protico

Does this mean that all <100% procs should have similar lag-gaps between when they are generated and when they are logged? Maelstrom Weapon would be a good indicator of this.

Here is some combat log:

It does look like MW is applied sooner than WF is by a substantial margin, and it is also applied at the same time as other procs (trinkets, UR, flurry). So it isn't just that the server has to RNG for WF, there is something else going on.

 

Tramana

I think it's because windfury generates new hit events (that need to calculate their hit, crit and value) that it's delayed, not the fact that it's <100%.

If you check flametongue procs I think you'll find they lag by quite a bit too. At least that's what I remember from doing FT testing a few weeks ago.

 

Mman

If you want to test something alongside of this that <%100 and procs a new hit event add in static shock to the test. I would think there would be a delay equivalent to that of a WF proc. (although static shock is only 1 hit and cannot miss/crit, so I suppose the lag might not be as long)

 

Protico

This is the longest gap I could find in the log I am looking at:

Most of the shorter gaps are hard to judge because there are multiple melee hits over the course of a few seconds prior to the Lightning Shield hit. Due to the hit table method of decision making hit/crit/glance shouldn't change the timing, but 1 vs 2 decisions certainly might.

 

Rouncer

More then likely that Flametongue hit is actually due to a previous melee hit and not that hit. I'm guessing you are using WF/FT which would also prove that point since for a glancing hit to do 705 damage it has to be a mainhand hit not an offhand hit. For an offhand glancing (25% less damage) blow to hit for 705 damage, even with a 156dps 2.5 speed weapon, it would require 8344AP which seems a bit out of reach even with full raid buffs.

Here is a combat log entry from a patchwerk where the weapons happened to hit basically at the same moment (2.6 mainhand and 1.6 offhand) and the mainhand windfuried.

The Flametongue and the Windfury attacks arrive at the same moment even though the mainhand attack that procced the windfury hit 0.2seconds before the offhand attack.