Authors CurseForge

Quote from Xinhuan

I think it will fail on macros. Does it work on [target=Xinhuan] macros where the player name is spelled out directly (many arena players use such macros)? Or target=unitIDs?

And then there's self-cast, focus-cast modifiers which might not be active. Say Alt is the self-cast modifier, and 4 is binded to HealA, hitting Alt+4 would self-cast HealA. But if Alt+4 is also separately binded to HealB, HealB wouldn't be considered a self-cast even though Alt is held down.

It depends what you mean by fail, if you're casting by name then your heal in general isn't going to be 100% accurate if you have duplicate names so you aren't exactly losing accuracy in messages.

When you do a /cast macro with [target=blah] the game calls CastSpellByName(spellName, "blah") thought so you can still get who it's supposed to be healing even then.

WoW is actually pretty smart with how it handles self/focus cast modifiers internally, all of the cast/UseAction functions will pass a nil unit when either it's waiting for a target (Binding Heal with no target/Self cast off) or it will pass unit when it's 100% sure who it's targeting. In your example it UseAction looks something like:

Click Nourish while targeting Xinhuan: UseAction(1, nil)
Click Regrowth while targeting Xinhuan while holding ALT: UseAction(1, "player")

Since xbeeps is going to be sending two messages regardless, have to see if there is a way of pulling both together maybe though.

Yes, but if you hook CastSpellByName() and all its other variants, you will also need to listen to all the various error messages returned such as not having enough mana, you are stunned, you are feared, etc. Basically, CastSpellByName() occurred, you hooked the spell and discovered the player wants to cast a heal on some party member, but the spell never actually got casted at all, not even a SPELL_CAST_START event.

Also, if the player is jabbing many spell buttons repeatedly, the last call to CastSpellByName() might not necessarily match the next error message or the next SPELL_CAST_SENT/START/SUCCESS. Even the error messages have a throttle in the default UI.

[Note, players like me from asia/australia play with an average ping of about 400-600ms. With SSH tunneling, we reduce this to about 200ms (Lowerping/etc). And you can press a lot of buttons within 200ms. Now throw in Wintergrasp lag into the equation.]

Quote from xbeeps

You just can't give it up? I've given you more than adequate justification for why the change cannot be accepted into LibHealComm-3.0 (see http://forums.wowace.com/showpost.php?p=285440&postcount=357). It's unnecessary and distasteful to spread FUD about the code being "flawed", just because it is not made exactly the way you want. The fact that i reject the proposol does not mean I'm rejecting collaboration, and in fact there are several contributers to the LibHealComm-3.0 codebase, and through the times there has been multiple developers who have contributed and optimised the code. You should learn that when collaborating you cannot always get your way.

Xbeeps, your goal now is simply to improve your library and maintain your "leading market share". Addon ideas aren't patented. While in general I disagree about the motivations behind LibIncomingHeals-1.0, there isn't any real grounds why curse or wowace should stop this library from being created either.

Quote from Elsia

I didn't read anywhere that xbeeps asked for curse or wowace to do anything, or did I miss something? If he didn't this is just agitating an already agitated situation I think.

He didn't. I'm just spelling it out clearly because Phanx has been quite discouraging about the library's overall usefulness and barriers to entry and it could be mistaken otherwise.

Pulled in the last of the healing data today, going to give it one more check over and I'll go do more testing of the GUID checking and then pull in the comm code and API's and it should be ready for testing.

Quote from Xinhuan

Yes, but if you hook CastSpellByName() and all its other variants, you will also need to listen to all the various error messages returned such as not having enough mana, you are stunned, you are feared, etc. Basically, CastSpellByName() occurred, you hooked the spell and discovered the player wants to cast a heal on some party member, but the spell never actually got casted at all, not even a SPELL_CAST_START event.

Also, if the player is jabbing many spell buttons repeatedly, the last call to CastSpellByName() might not necessarily match the next error message or the next SPELL_CAST_SENT/START/SUCCESS. Even the error messages have a throttle in the default UI.

[Note, players like me from asia/australia play with an average ping of about 400-600ms. With SSH tunneling, we reduce this to about 200ms (Lowerping/etc). And you can press a lot of buttons within 200ms. Now throw in Wintergrasp lag into the equation.]

I'll double check it in the morning if I can come up with an easy way of simulating lag for a long period of time, I've been testing it with 150-200 MS without noticing issues even with spam clicking. But it might be that I need to set a throttle or force it to "lock" a cast from having the GUID changed until the cast is either interrupted or stopped.

It doesn't specifically default to the last entry pressed though, it goes by a priority of how reliable the GUID would be and won't let equal priorities override another equal one and all of the spammable ones are locked to this.

Quote from Xinhuan

Xbeeps, your goal now is simply to improve your library and maintain your "leading market share". Addon ideas aren't patented. While in general I disagree about the motivations behind LibIncomingHeals-1.0, there isn't any real grounds why curse or wowace should stop this library from being created either.

To be fair, I've considered writing this for a while I just ended up with extra motivation to do so. But either way, regardless of what others might think since it's an interesting project and has been fun to work on.

Quote from Nandini

From what I read earlier today, there appeared to be a new modicum of cooperation and collaboration among the potential library authors. It might be best to avoid disturbing this balance if it still exists. :) (Even if the addon authors who might be using the libraries choose to nitpick about protocol revisions.)

Probably not it looks like actually, but since HealComm is going to start sending out two messages from now on there isn't really anything lost by making the wrapper send data if it's not too much of a pain.

I can't usually get torrents to go fast enough that it actually lags my connection, although I could go download a bunch of Linux distros.

Quote from Nandini

A good way to experience lag is to do a peer-to-peer download of several large files with several incoming and outgoing connections while participating in a Wintergrasp battle on Tuesday or Wednesday.

No need to "simulate" the lag when you can observe it in its native habitat. :)

There is even a multitude of players (who actually need healing!) to heal, who may or may not be in your raid.

That's causing packet losses to occur, which isn't the same as simply having a connection that has a latency (ping) of 500ms.

The first causes "bursts" of action catching up when the lost packets have been resent and received and everything in the buffer is sent at one go.

The second is just a constant slower reaction time between the server/client.

To properly simulate a high latency connection, you should just tunnel your connection across the world (incidentally tunneling removes Nagel's Algorithm by default, reducing latency).

Mmmm, aren't the servers for tunneling usually either poor or paid? Although it might be a bit easier than moving to Australia.

Quote from Shadowed

Mmmm, aren't the servers for tunneling usually either poor or paid? Although it might be a bit easier than moving to Australia.

I use wowtunnels which is one of the cheapest ones, and still offer outstanding stable connections. Almost all of these tunneling services have free servers/tunnels you can use for trial purposes, although they usually disconnect you every 15 or 30 minutes when on the trial servers.

Quote from Xinhuan

I use wowtunnels which is one of the cheapest ones, and still offer outstanding stable connections. Almost all of these tunneling services have free servers/tunnels you can use for trial purposes, although they usually disconnect you every 15 or 30 minutes when on the trial servers.

Is there an actual timing difference between 600 MS high latency and 600 MS high latency from downloading torrents event wise? All of the targeting is done locally so the cast timing on all of the function calls is the same, and SENT is also called instantly regardless. the START and other events still have a delay which is ultimately what you're trying to test.

Quote from Shadowed

Is there an actual timing difference between 600 MS high latency and 600 MS high latency from downloading torrents event wise? All of the targeting is done locally so the cast timing on all of the function calls is the same, and SENT is also called instantly regardless. the START and other events still have a delay which is ultimately what you're trying to test.

The difference is consistency. The 600 ms obtained thru tunneling would be a consistent 600ms.

The 600ms obtained thru torrents causing packets to be lost will be erratic and spikey, and its really just an average of say your usual 50ms and a 18000ms spike.

My question is, what if you cast 3 spells at one go, before you get a response from the server regarding their success or failure?

You mean cast as in, you press a button that's bound to a spell or cast as in a SENT event fires? SENT can only fire once until the client is told the cast is "unlocked" through an event and a new one can be sent, since it's a secure hook the game will always fire SENT first then UseAction/etc. The only time it won't is when it's waiting for a target, but that's a lot easier to handle.

Redid/cleaned up the detection code again and added debug code so it will figure out and warn if it found the wrong GUID. It doesn't actually do anything yet (no comm data is sent, no heals calculated etc) but I just need real use testing before I proceed with adding everything else in and start beta testing it all.

All you need to do is download http://www.wowace.com/addons/libpendingheals-1-0/ and run it, if it finds a bad GUID it will report to chat that it did and then I need the debug info on why it failed to find the GUID. It'll throttle it at one report per 5 minutes though, so if there is a serious bug it won't spam you.

If you see no "WARNING! LibPendingHeals-1.0" message then it's running fine (Which would also be good to know!) the only thing it won't support right now is healing through a /targetlast macro with self cast off.