The lag/reaction time doesn't matter of procs happening from abilities. Since GCD is more than long enough to cover any kind of normal lag and human reaction times by the time you can do your next ability. Moreover, Redcape's 'friend' with the T10 set seems to have already confirmed my initial assumption that the proc would happen off melee white swings only, which if true, makes this point entirely moot anyway.

So the only difference it will make is procs happening off autoattacks near the moment you would hit an ability.

Going by that...
Situation One: Moot, unless procs can happen of abilities.

Situation Two: I was not suggesting that waiting is a good thing. However, there is a clear difference between.
The human presses Cons, while the 'robot' can still press DS instead. They both have the same lag, but the human suffers an extra penalty.
At this particular moment in time it means hitting DS over Cons. An ability that does more damage. It would be naive to say now "oh but the human will just hit DS next then GCD", but this isn't necessarily so, if DS is first in the priority then yes. If something else is higher in the priority then that might be next.
In any case, the user pressing Cons, and the robot pressing DS do change the entire stream of abilities being hit after it. How much of a DPS difference does it make ? Probably not a whole lot, but it is there. Human reaction on top of lag made the difference.
Even more lag and even slower human reactions will increase the likelyhood of missing the DS proc at the earliest possible time.



Situation three: Correct, but since you react in time, it makes no difference.

Situation four:
Again correct but... The right approach for the lagging user would be to hit Cons (since waiting is bad). The lagging robot would've hit DS. Again, a difference between the human and the "robotic" situation. Prooving that the simple delay isn't entirely modelling things right. You could increase the delay to compensate, but then you incur a delay on EVERY ability you hit rather than just the few times a melee swing happens a split second before you'd hit an ability.



It's true GCD is there to help minimize the effects of lag. I already pointed that out in my post, the server even compensates by accepting the next button before the GCD is really over (it doesn't execute the ability early, it just accepts and queues it for when the GCD is over).
But with "react to random proc", lag and reaction are effective factors.


It's not going to be a huge difference in DPS. The melee swing needs to be close to the end of a GCD to begin with, and the DPS difference between various abilities isn't that big on single target. On multitargets, getting that few more DS in over something else might make a bigger difference.
The above shows the extra human reaction on top of the lag/delay does make a difference. You hit something else instead of DS, and this changes the rest of the FCFS sequence after it.
If easy to do, maybe give it a try in a debug/test build of rawr to see in what order of difference the DPS is?

While your looking at the above im having an odd issue with the rotation selector. When i choose different rotations the dps listed doesn't change, even when it can calculate it correctly.

Situation:

Have only standard rotation shows dps at 9k
add now rotation showing DS first, dps is at 10k

Select standard rotation, dps still at 10k, select new DS rotation, still at 10, delete new rotation, dps listed drops to 9k.

P.S. Also there is some conversation going on 3.3 thread regarding the new rotation not being an actual increase, do you know how yours differes from theirs and how yours is showing more dps?

That seems to be the case. In Rawr the 2P T10 is worth 700 DPS. Redscape has updated his model and it's coming out as a bit less than 400 DPS.

Although neither models 2P T10's weird interaction with Seal of Command that has been noted by another poster. The two cleaves from a white hit appear to act as additional opportunities to refresh DS. The cleaves from yellow hits do not display the same behavior.

Sorry for bump, but since the proc is still bugged in 2.3.3, I'd like to make sure you haven't missed my post.