great, now we just need to get a TOC update and a push on http://www.wowace.com/addons/onebuttonconfig/
Unless you want people to ignore it further into oblivion.
- Registered User
Member for 11 years, 1 month, and 3 days
Last active Sat, Jan, 27 2018 22:35:21
- 0 Followers
- 511 Total Posts
- 0 Thanks
Nov 19, 2010yes, but keep in mind this is a client side setting. If you set it high (for example 400ms) and you attempt to cast a spell 300ms before the GCD completes (the spark reaches the end), and it takes the command only 200ms to reach the server (because of real-life network latency fluctuations), the server will reject the command, and you'll have to retry. Previously the client would simply not allow you to attempt send the command until the global cooldown was over.Posted in: General AddOns
Nov 19, 2010That's not a latency queueing slider, and it doesn't affect the latency. The red zone shows the latency. How that relates to when you can cast another spell is another matter. The slider affects how soon before the global cooldown completes you can (attempt to) cast a new spell. It does not affect how soon before a spell cast ends you can cast a new spell (unless the spell cast time is shorter than or equal to the global cooldown, in which case the global cooldown becomes the dominating lockout).Posted in: General AddOns
Nov 8, 2010Castbars is up an running and working fine, also on the PTR, so it is ready for Cataclysm. In fact i think it is the only castbar addon that properly supports the new channeling ticks mechanics with the ability to show the extra ticks gained through haste on some channeling spells.Posted in: General AddOns
I'm currently working on some visual improvements such as icon and border customization, and the next push will contain new textures unique to Castbars to make it prettier out of the box.
Oct 24, 2010xbeeps posted a message on What do all the errors in FrameXML.log mean anyway?Actually the loading time penalty is quite significant when entries are made in this log. This is usually the first place i look if my loading time has grown annoying.Posted in: General Chat
Oct 17, 2010Does anybody know (or can test) if the amount returned by UnitGetIncomingHeals is modified by auras that affect healing, such as http://www.wowhead.com/spell=13583 or http://www.wowhead.com/spell=12294 ?Posted in: Lua Code Discussion
If that is accounted for, will UNIT_HEAL_PREDICTION be fired when such auras are applied or removed?
Also, I notice that for hots, only the next tick is included in the amount. Have anyone experimented and figured out if the amount is for a fixed amount of time into the future (for example next 3 seconds), or is it simply the sum of the next direct heal (if any) and next hot tick (if any) regardless of how long till they occur?
Apr 25, 2010You can't really quantify the amount of CPU it uses in a meaningful way. There are two contributing factors. One is that the combat log events are extremely frequent - take a look at the combat log in a 25man raid during an encounter (and this is usually only some of it). When several addons are listening to this event noticeable lag is introduced (on all but the most powerful systems), simply because of the shear amount of code that is executed for each and every event (even those events that are useless to each addon, which is the vast majority). The other factor is code size. I estimate that it would increase the code size by 50%, and because there are no clear events suitable for a precision swing timer, it will be complex and messy code that will be harder to maintain (requires special handling of some abilities).Posted in: General AddOns
That is why i (still) recommend that someone get rolling and implement this as a standalone addon, instead of plugging it into various castbar addons (to which it really doesn't have any relation except perhaps for the most likely positioning on the screen).
Mar 12, 2010The repository is open so changes can be pushed (Phanx has already done so). To push a release though, probably requires author-rights, which you can only get from Dathrarhek or perhaps an admin, if Dathrarhek does not respond anymore.Posted in: General AddOns
Mar 11, 2010Posted in: General AddOnsQuote from MorgalmYeah that would explain it I have no cross realm members in my raids. Thus it works perfectly. And yeah I seem to be getting the right messages at the right time as far as I can tell.
So I assume that all the Unit functions expect the name only correct? As in UnitIsDead("player") not UnitIsDead("player-realm"). So why in the above code would we need to add realm back in ever. Just strip every name of realm and check it no?
For players on your own realm UnitIsDead("playername") works, but UnitIsDead("playername-myrealm") does not work.
For players on other realms UnitIsDead("otherplayername") doesn't work, but UnitIsDead("otherplayername-otherrealm") does work.
Or in words: players on your realm shall not contain the realmname, players on different realms shall always contain the realmname.
The issue arises when players on different realms adhere to these rules when sending messages to each other. Thus, the need for translation which can cause either insertion of a realm (which is always the realm of the sender), or deletion of the realm (when someone from a different realm sends messages about players on your realm).
Mar 10, 2010Posted in: Libraries
Fixed Paladin heals returning 0 when they are crits and the Paladin doesn't have Touched by the Light
I assume this explains why GetHealAmount returns nil for the player in the very function call that states the player is casting a heal, thus explaining the error cremor is seeing?
Mar 10, 2010It's better to use unit names rather than units. All API functions that take a unitID can also take a unit name as long as you're grouped, which is always the case.Posted in: General AddOns
Anyway, you need to make sure the code is aware of the fully qualified names ("Name-Realm"). I just checked the LibResComm code and it currently isn't, but it can be fixed in the addon, if you want to, because it only affects reception.
When you receive a ress message you need to consider if the name of the target is really correct. Consider this:
Player P1 is on Realm A
Player P2 is on Realm B
Player P3 is on Realm B
P2 resses P3
P2 will transmit a message where it says "RES P3". Because P2 and P3 are on the same realm the name given will be "P3", because that is the fully qualified name as seen from P2.
However, from the point of view of P1, who (also) receives the message, "P3" is known as "P3-B", because P1 and P3 are on different realms.
Another situation is when for example P3 resses P1. When P1 receives that message it will be "P1-A", and the realm needs to be stripped from that name to actually work. Note that P2 will also receive the message, but will *not* have to strip the realm!
Consequently, if nothing is done about the name, it will not be successfull when using the name in API's.
To fix that, you need to convert the names received. In LibHealComm-3.0 i use the following code to do that:
local function extractRealm(fullName) return fullName:match("^[^%-]+%-(.+)$"); end -- Convert a remotely generated fully qualified name to -- a local fully qualified name. local function convertRealm(fullName, remoteRealm) if (remoteRealm) then local name, realm = fullName:match("^([^%-]+)%-(.+)$"); if (not realm) then -- Apply remote realm if there is no realm on the target return fullName .. "-" .. remoteRealm; elseif (realm == playerRealm) then -- Strip realm if it is equal to the local realm return name; end end return fullName; end
Then, when you get a name in, you do something like this:
targetName = convertRealm(targetName, extractRealm(sender))
Where targetName is the name of the target and sender is the name of the player sending the message.
Ideally this should be build into LibResComm-1.0 similar to how it is built into LibHealComm-3.0, so that the fully qualified names delivered by the library are always correct instead of reflecting the sender's realm.
- To post a comment, please login or register a new account.