Sorry about that, the patch hasn't hit here yet (EU), and i didn't expect it to cause any ill side-effects so i didn't want to bother with PTR testing. I've fixed the problem which is caused by Mana Drain being removed from the game. Let me know if there's anything else, as i can't test on 4.0.6 until tomorrow.
Sorry about that, the patch hasn't hit here yet (EU), and i didn't expect it to cause any ill side-effects so i didn't want to bother with PTR testing. I've fixed the problem which is caused by Mana Drain being removed from the game. Let me know if there's anything else, as i can't test on 4.0.6 until tomorrow.
Thanks for the quick fix, regardless! I'll give it a run, and if I run into any other issues, I'll make a note.
(And if I don't, well.. I'll be busy running heroics. Haha.)
1. Is it possible to disable the mirror bars as it is for all of the other bars?
2. I notice that the countdowns on the mirror bars are not in sync with the correct buff CD. For example, Feign death counts down from 6 minutes but goes to -5.0 seconds before the effect wears off. Same with fatigue/breathing for damage to occur, it's about 5 seconds out of sync. Is it possible to check this out?
To anyone who feels like this new latency bar display change is ruining their timing, open up Interface Options -> Combat and fiddle with your Custom Lag Tolerance setting.
Previously, I had this setting disabled (which I think it says that the default is 400ms). My latency tonight was around 35-40ms. I tried the new version of Castbars and was hating that I couldn't get my spells off at the right time, and was confused as to why the red latency bar was so large if my latency was so small. So, because my hubby's so smart, I turned on custom latency, moved the slider down to 50, and tried again. Now the latency bar is accurate again.
There are several aspects to it. First, with the new queue system it is no longer possible to measure the "instantaneous" latency, because the time between UNIT_SPELLCAST_SENT and UNIT_SPELLCAST_START is no longer only the client-server roundtrip time, it is also the time the spell is waiting on the (server side) queue, which depends on how early you cast it when chain casting. This is quite easily visible if you take the old version (or Quartz which is still using the now flawed measurement) and chain cast spells. Then you will notice that if you cast the spell really late just before the current spell times out, the following latency indicator will be really short. Conversely, if you cast the spell really early (and still get it to cast with no errors), the following latency indicator will be very long.
Before the spell queue was added to the server, it worked in a way were the server would actually allow the spell to go off up to 0.4 sec earlier than the GCD. That's why it was so important to have the latency indicator, because you really needed to fire that spell as early as possible, to get as little down time as possible between the spells (which increased DPS and made people bind spells to their scroll wheels and use macro keyboards). Now, with the spell queue, that doesn't work anymore, and you have much more room to get the spell out, because the spell will be queued server side and started when the previous spell stops, instead of started early (thus DPS is invariant of how early you cast it, as long as it just gets to the server before the current spell is done). This means that you do not have to trigger the next spell exactly at the point were the latency indicator starts anymore, but just somewhere inside it (but not too late, or the spell will expire on the server).
Because of this, i have changed the way the latency indicator works, so instead of showing you just the latency, it shows you the queue zone (0.4s), adjusted to consider the current latency as well as the local global cooldown lockout (which in turn is adjusted by the custom latency tolerance slider). Because the "instantanous" latency cannot be measured accurately, except for the first cast, the world latency (which is probably not the one you're reporting? it's the 4th return value from GetNetStats, most ping addons show the 3rd return value) is used as the basis for adjusting the queue zone display. This is actually a pretty good measure, because once you have start chain casting spells the downstream latency and processing time matters less because the time the server spents doing this is while the previous spell is casting, so it gets the request on the queue while it is idle anyway, and once the next spell begins it just triggers the UNIT_SPELLCAST_STOP and UNIT_SPELLCAST_START in one go (so these are rarely more than a few milliseconds apart when chain casting).
Regardless, when dealing with latency, you can never know, even if you just measured the latency, whether the latency of your next command will be the same, so there is no certainty in these things. But my main point is, that you should not attempt to fire your next spell exactly where the queue zone indicator begins, rather you should aim at triggering it at a point where you are sure it is inside the queue zone.
With that being said, it *is* important that you set the custom latency tolerance slider correctly, as you suggest. If you set it too high, the client will allow you to send a spell request too early, and the server will reject it. If you set it too low, the spell queue zone will be so small (for 1.5sec base cast time spells) that you won't get the spell across to the server before the previous cast is over, and your DPS will suffer as the gap between spells increase.
Ah, I do see now that that was showing my UI latency rather than world latency. I will have to do some more testing and fiddling.
Here is the difference that I'm feeling. Before, I could just do two-taps of my button to cast (I detest button mashing). The first would hit *just* before entering the red area, the second just after. My casts went off just fine, unless I was having latency issues where it was going up/down mid-cast of course. Last night, using the same method, a lot of my casts weren't getting queued up. I had to button mash (at least 4 taps) to get the spell to cast, and there seemed (though it may have just been me, being thrown off already) to be a *slight* delay in the cast bar changing over to the new cast.
Ah, I do see now that that was showing my UI latency rather than world latency. I will have to do some more testing and fiddling.
Here is the difference that I'm feeling. Before, I could just do two-taps of my button to cast (I detest button mashing). The first would hit *just* before entering the red area, the second just after. My casts went off just fine, unless I was having latency issues where it was going up/down mid-cast of course. Last night, using the same method, a lot of my casts weren't getting queued up. I had to button mash (at least 4 taps) to get the spell to cast, and there seemed (though it may have just been me, being thrown off already) to be a *slight* delay in the cast bar changing over to the new cast.
Happened a few times for me aswell (Hunter spamming steady shots). Sometimes the castbar is lagging behind, but i see myself firing the shot but the castbar shows up a little late and it's not visible for more than a few milliseconds.
Seerah: do not tap it before it enters the queue zone! If you tap it just before you enter the queue zone the request is sent to the server and you're locked out until you get a failed response back, so that is probably locking out your next two taps, so it isn't until your fourth tap you get it through. If you tab just once inside the queue zone it'll work fine, because then the server will accept it and queue it.
Skylinee: i'm not sure what you're talking about. What do you mean the castbar is lagging behind? This has nothing to do with how/when the castbar is shown or the movement of the progress bar on the castbar, which is handled exactly the same as always, and exactly the same as in any other castbar addon (including the standard castbar). It's a well known fact that the client side castbar is lagging behind the actual cast on the server (it's always been like that).
there is just 3 little things missing imho:
fine tuning for border textures, almost no textures i have fits good.
non-interruptable spell handling, i have always the icon showing, even if i set no icons.
font size handling, i'd like to have different sizes for name and time.
I would only consider that as a last resort, as i don't want to clutter the options panel with weird parameters. I'm still interested in knowing what textures we're talking about, because all the standard ones fit fine with the current ratio between bar size and edge size.
Because if you scale the bar down, the border becomes near invisible with some textures. Depending on the dimensions of the border texture used, there are different optimal edgeSize values.
Again, any custom textures with a different width (thickness) or a different size (dimension) than the default border textures. You provide support to use custom textures through LSM as well as the ability to change the size of the cast bar frame. But sometimes custom border textures require the ability to tweak their edge size. This allows the user to scale the texture themselves to fit the desired frame size. Either to prevent overlapping or to make the texture visible. Other textures look best at a certain edgeSize and odd at others.
edit: This is your addon. And you have the right to say 'no' to any feature request. I do it all the time. :) But it's been mentioned for a while that your current border scaling implementation doesn't work for custom borders. I, myself, have had to work around it and choose different borders that don't match the others in my UI or had to go without in this addon in the past. Again, totally up to you if you want to say no - I know that I will respect your decision. But the way your code assumes which edgesize we want is not the best practice.
Could the ticks for channeled spells be moved after a pushback? I find myself guessing when to clip on bosses with aoe pushback mechanics (poison nova Maloriak, nefarian shadow stuff Chimearon, etc)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Locals:
---
That's the error I get on login. Castbars do not show up.
Thanks for the quick fix, regardless! I'll give it a run, and if I run into any other issues, I'll make a note.
(And if I don't, well.. I'll be busy running heroics. Haha.)
Couple of questions:
1. Is it possible to disable the mirror bars as it is for all of the other bars?
2. I notice that the countdowns on the mirror bars are not in sync with the correct buff CD. For example, Feign death counts down from 6 minutes but goes to -5.0 seconds before the effect wears off. Same with fatigue/breathing for damage to occur, it's about 5 seconds out of sync. Is it possible to check this out?
Thanks
Not reliably and definitely not efficiently.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumPreviously, I had this setting disabled (which I think it says that the default is 400ms). My latency tonight was around 35-40ms. I tried the new version of Castbars and was hating that I couldn't get my spells off at the right time, and was confused as to why the red latency bar was so large if my latency was so small. So, because my hubby's so smart, I turned on custom latency, moved the slider down to 50, and tried again. Now the latency bar is accurate again.
/edit: nvm - it still has its touchy moments...
Before the spell queue was added to the server, it worked in a way were the server would actually allow the spell to go off up to 0.4 sec earlier than the GCD. That's why it was so important to have the latency indicator, because you really needed to fire that spell as early as possible, to get as little down time as possible between the spells (which increased DPS and made people bind spells to their scroll wheels and use macro keyboards). Now, with the spell queue, that doesn't work anymore, and you have much more room to get the spell out, because the spell will be queued server side and started when the previous spell stops, instead of started early (thus DPS is invariant of how early you cast it, as long as it just gets to the server before the current spell is done). This means that you do not have to trigger the next spell exactly at the point were the latency indicator starts anymore, but just somewhere inside it (but not too late, or the spell will expire on the server).
Because of this, i have changed the way the latency indicator works, so instead of showing you just the latency, it shows you the queue zone (0.4s), adjusted to consider the current latency as well as the local global cooldown lockout (which in turn is adjusted by the custom latency tolerance slider). Because the "instantanous" latency cannot be measured accurately, except for the first cast, the world latency (which is probably not the one you're reporting? it's the 4th return value from GetNetStats, most ping addons show the 3rd return value) is used as the basis for adjusting the queue zone display. This is actually a pretty good measure, because once you have start chain casting spells the downstream latency and processing time matters less because the time the server spents doing this is while the previous spell is casting, so it gets the request on the queue while it is idle anyway, and once the next spell begins it just triggers the UNIT_SPELLCAST_STOP and UNIT_SPELLCAST_START in one go (so these are rarely more than a few milliseconds apart when chain casting).
Regardless, when dealing with latency, you can never know, even if you just measured the latency, whether the latency of your next command will be the same, so there is no certainty in these things. But my main point is, that you should not attempt to fire your next spell exactly where the queue zone indicator begins, rather you should aim at triggering it at a point where you are sure it is inside the queue zone.
With that being said, it *is* important that you set the custom latency tolerance slider correctly, as you suggest. If you set it too high, the client will allow you to send a spell request too early, and the server will reject it. If you set it too low, the spell queue zone will be so small (for 1.5sec base cast time spells) that you won't get the spell across to the server before the previous cast is over, and your DPS will suffer as the gap between spells increase.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHere is the difference that I'm feeling. Before, I could just do two-taps of my button to cast (I detest button mashing). The first would hit *just* before entering the red area, the second just after. My casts went off just fine, unless I was having latency issues where it was going up/down mid-cast of course. Last night, using the same method, a lot of my casts weren't getting queued up. I had to button mash (at least 4 taps) to get the spell to cast, and there seemed (though it may have just been me, being thrown off already) to be a *slight* delay in the cast bar changing over to the new cast.
Happened a few times for me aswell (Hunter spamming steady shots). Sometimes the castbar is lagging behind, but i see myself firing the shot but the castbar shows up a little late and it's not visible for more than a few milliseconds.
Skylinee: i'm not sure what you're talking about. What do you mean the castbar is lagging behind? This has nothing to do with how/when the castbar is shown or the movement of the progress bar on the castbar, which is handled exactly the same as always, and exactly the same as in any other castbar addon (including the standard castbar). It's a well known fact that the client side castbar is lagging behind the actual cast on the server (it's always been like that).
fine tuning for border textures, almost no textures i have fits good.
non-interruptable spell handling, i have always the icon showing, even if i set no icons.
font size handling, i'd like to have different sizes for name and time.
it could be perfect to me with 3 issues solved
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBut if you really want to see for yourself... try some of these: http://www.wowinterface.com/downloads/info15613-FerousMediaPack.html
edit: This is your addon. And you have the right to say 'no' to any feature request. I do it all the time. :) But it's been mentioned for a while that your current border scaling implementation doesn't work for custom borders. I, myself, have had to work around it and choose different borders that don't match the others in my UI or had to go without in this addon in the past. Again, totally up to you if you want to say no - I know that I will respect your decision. But the way your code assumes which edgesize we want is not the best practice.