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.]
Can you really tell the success or failure of a spell cast just by secure hooking these functions? (For example, if I am stunned for 6 seconds and am spamming Greater Heal a dozen times over those 6 seconds.)
I had this same concern 2 days ago, Xinhuan, and Shadowed's next post said it could be accounted for in about 100 lines of code. (He didn't quote anyone in his response, so he may not actually have been addressing my question and I may have completely misunderstood.)
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.
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.
Clearly the ideal is for people to throw their heads together and find a good common solution. But it's been dicey for two days now.
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.
Alright, fair enough. I didn't read Phanx's comments that way, but I totally agree that there is no grounds for wowace to worry about this. (heck I have asked often enough to get more leeway for new libs! ;))
I think lots of people are concerned about the dynamics, but I like that all sides do on and off signal interest in cooperation. Hopefully that'll work.
I'm still part excited too because there is innovation happening here, even if it may turn out tricky and all.
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.)
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.
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.
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.
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.
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.
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.
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.
I have about 400-800ms latency when using my 3G cellular provider's network. I've never tried playing WoW over that connection since it also tends to disconnect and reconnect frequently. Plus I'm not sure I could adjust to that kind of delay being used to playing over a fairly rock solid cable modem connection less than 10 hops from the game servers in my battlegroup. The only time I've used it with this computer was for basic browsing and email during a power outage when my battery backup lasted longer than the cable company's batteries.
Perhaps you have a cellular connection or a friend with one you can test with?
Also, the "lag" I mentioned from Wintergrasp is not really related to packet latency, but rather to server partition load. It happens when a game server partition is unable to process all the pending combat events as fast as they are being requested. This has mostly been seen with world server partitions lately, but is the same issue that was plaguing instance servers in 3.0 and 3.1 before server resources were reallocated. It's probably a situation that should be tested for separately from packet latency. I shouldn't have recommended testing both at the same time. :)
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.
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.
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.
I'm a forum moderator only, I have no say over what happens with projects or files, and I am strongly opposed to any kind of "project censorship". So, even if I think a library isn't a sufficient improvement over another, already established library to warrant the massive headaches for users and developers it would cause to try to cut into the market, I'll never say that the library should be removed from any site, and I certainly don't have any ability to remove it. :p
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
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.
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 had this same concern 2 days ago, Xinhuan, and Shadowed's next post said it could be accounted for in about 100 lines of code. (He didn't quote anyone in his response, so he may not actually have been addressing my question and I may have completely misunderstood.)
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.
Clearly the ideal is for people to throw their heads together and find a good common solution. But it's been dicey for two days now.
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.
I think lots of people are concerned about the dynamics, but I like that all sides do on and off signal interest in cooperation. Hopefully that'll work.
I'm still part excited too because there is innovation happening here, even if it may turn out tricky and all.
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.
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.
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.
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).
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.
Perhaps you have a cellular connection or a friend with one you can test with?
Also, the "lag" I mentioned from Wintergrasp is not really related to packet latency, but rather to server partition load. It happens when a game server partition is unable to process all the pending combat events as fast as they are being requested. This has mostly been seen with world server partitions lately, but is the same issue that was plaguing instance servers in 3.0 and 3.1 before server resources were reallocated. It's probably a situation that should be tested for separately from packet latency. I shouldn't have recommended testing both at the same time. :)
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?
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.
I'm a forum moderator only, I have no say over what happens with projects or files, and I am strongly opposed to any kind of "project censorship". So, even if I think a library isn't a sufficient improvement over another, already established library to warrant the massive headaches for users and developers it would cause to try to cut into the market, I'll never say that the library should be removed from any site, and I certainly don't have any ability to remove it. :p