WowAce

The current lag display - what all cast bar mods I know of show - is not a good indicator of when can one cast the next spell, especially on connection with high jitter (variance of delay): To combat delay and jitter, WoW implements a server-side spell queue, here is an in-depth article about how is this implemented currently: http://wowhats.wordpress.com/2010/03/07/lag-wow-and-you/

Here is a short summary:
a, There is a queue zone on the server beginning 300ms before the current cast ends (or before the GCD expires in case of instant spells), where queued spells will be cast immediately after the previous.
b, There is a 1s long lockout zone on the client, where you cannot queue anything (even within the 300ms queue zone). This zone begins at the start of any spell, be it instant or with cast time.

What I would like to see is that, instead of colouring the "lag" at the end of the cast bar, to colour of the effective queue area, stating 300ms before cast end but at least 1s after last spell cast start, (so lockout zone has "higher priority"). Considering how network delay affect the problem, these zones should be counted starting at client-side cast start. (I think it is the UNIT_SPELLCAST_SENT event, UNIT_SPELLCAST_START is at receiving the server's answer)

A related request originally presented in ticket 52: Also, a simple color selection for the latency bar would be awesome. This setting actually has two parts: 1) the actual color of the latency bar (default: red) and 2) the alpha of the latency bar (currently 100%). This would allow the user to have a similar effect to incoming health bars, being rather transparent but still visible.

Current implementation in r148 is not working correctly. First, if I try to cast at the begin of the "red zone", than I have an error that the spell in not ready. Second, if I cast channeled spell (Mind Flay for example), than last tic is lost.

The algorithm is not really tuned yet. I'm not going to release it like this. For channeling spells, it also needs to consider the last tick of course, but it doesn't yet. However, this is not an exact science. The exact timing on the server can only be estimated, the queue time we guess is 400ms based on some blue posts about the previous system (that allowed you to cast early if you tried), and the network latency at any one point can never be predicted (even if you know what it is "right now" there no guarantee that if you sent a command, it will take that amount of time to get there, it may suddenly be faster, and therefore rejected because it arrives at the server prior to the queue zone). So there is always a risk that any spell will be rejected by the server even if it is cast inside the queue zone.

I made a post about this in the comment thread, but it doesn't seem like castbars takes into account the Custom Lag Tolerance setting (Interface/combat), which can be used to adjust the spell queue window.

Custom lag tolerance does not affect the spell queue window. It only affects how early the client will allow you to *attempt* to send a request to the server to queue something. It doesn't increase the window were you can actually queue something.

Well, perhaps I'm misunderstanding or miscommunicating something. For a while I've been playing with >300ms latency (as described in game and indicated on Castbars) due to a bad modem. I've had the modem replaced and my latency is 75ms, as indicated in game. However, Castbars (v148) still shows the last 400ms of a castbar in red. Quartz correctly shows just the last 75ms. I assumed this was due to highlightning the Blizzard lag tolerance zone.

For the record, backing up to R3.8 correctly shows my sub 100ms latency.

If you're using the latest release, it shows exactly the same thing as Quartz. If you are using the latest alpha it shows 500ms + half of what it used to show for the first cast and 500ms + half of the average measured latency for queued casts.

Where does the 500ms come from? Now that my latency is actually low, I'm finding that with the Alpha (v148) I often dont get spells queued when i hit them "in the red."

The release R3.8 works perfectly at the moment, but does not label the Blizzard Lag Tolerance setting.

it just the value i had there when i submitted it. It's not going to be like this. Please use the release, unless you need to test something specific.

Take r152 for a spin. I think i'm going to release that.

In 3.10