Page 7 of 9 FirstFirst ...
5
6
7
8
9
LastLast
  1. #121
    Quote Originally Posted by robbymottec View Post
    if it was bot/hack it should have reflect 100% of your hoj, OP is butthurt because he lost x1 as healer.
    If it's a bg and they are stacked up gy camping he could've been using it on cd to reflect various abilities. The fact that it isn't 100% means nothing as it could've been on cooldown. Try reading bud...

  2. #122
    The Patient
    Join Date
    Jan 2010
    Location
    London
    Posts
    274
    Quote Originally Posted by rda View Post
    Are you sure it works like that - ie, the server first sends everyone SPELL_CAST_SUCCESS for HoJ (meaning the server sends a packet that makes clients trigger SPELL_CAST_SUCCESS events, I am just shortening this), and then, even though the server knows that HoJ has already been cast, it still continues to register packets from clients that might tell it "hey, I just used Reflect / Cloak", which alter the server state of the relevant players, and it is after that when the server finally goes to check whether HoJ has actually landed or has been reflected by whoever it was thrown on? It seems illogical to first send a confirmation "OK, you did your HoJ" and then to check whether that HoJ actually had an effect. My understanding was that the server first determines whether a HoJ lands and then sends relevant packets. My understanding of how the cloak works was that they tried to make it work via regular means for a long time (I remember seeing lots of complaints on cloak some years ago), couldn't get it to work reliably, and did more or less a hack to make cloak apply the instant the caster (rogue) used it, adding special logic which kinda breaks the rules. Maybe they extended the hack to cover HoJ, too, but that'd be the first time I hear about it.

    Not 100% sure about your theory on cloak.

    To answer your question in bold tho, your method would make sense if all spells were instant, it would be more efficient to check wether or not it landed before giving the success since they have no cast time than can be stopped. Unfortunatly it becomes very inefficiant when a spell has a cast time.

    Look at it like this, a cast time spell and an instant spell are the same in the fact that they both are spells regardless.

    However if your 2s cast is interrupted/cancelled manually or for whatever reason does not finish, then if the server checks to see whether it lands before the cast is complete then that is a whole packet of useless data and iterations it did not need to calculate.

    Add a 25 man raid, so multiple players chain casting spells that constantly never complete due to movement/fight mechanics, then you can see why its extremely inefficient for the server to behave as you suggest, there would literally be millions of wasted packets of data for spells that did not complete their cast, so its actually very logical to only roll AFTER a SPELL_SUCCESS

    Hope that clears it up?

  3. #123
    Quote Originally Posted by villie View Post
    Hope that clears it up?
    Yes, I understand what you are saying.

    It is possible that doing the checks after sending SPELL_CAST_SUCCESS for all spells, instant or not, is just simpler code-wise. It is also possible that doing the checks before sending anything for instant spells is not any more difficult. That depends on how the code is structured. I agree that it is possible that Blizzard do it the first way. The story of them not being able to make the cloak - and vanish - work reliably for a long time is real, after all.

  4. #124
    He just explained why doing checks before is more difficult, how dense do you intend to be?

  5. #125
    Instant reflect is no longer a thing. Not even harm macro can do the job, since they added some delay to spell reflect.

  6. #126
    The Patient
    Join Date
    Jan 2010
    Location
    London
    Posts
    274
    Quote Originally Posted by rda View Post
    Yes, I understand what you are saying.

    It is possible that doing the checks after sending SPELL_CAST_SUCCESS for all spells, instant or not, is just simpler code-wise. It is also possible that doing the checks before sending anything for instant spells is not any more difficult. That depends on how the code is structured. I agree that it is possible that Blizzard do it the first way. The story of them not being able to make the cloak - and vanish - work reliably for a long time is real, after all.
    Blizzard do it the first way, not possible, they do for the reasons i have already given, as for how the event code is structured, this is how a spell is classified.

    SPELL_ Spell is the prefix for most effects even if the spell is a DoT or channeled. IE when the spell begins to be cast, SPELL_CAST_START is fired and not SPELL_PERIODIC_CAST_START. This is the same with _MISS, _FAILED, etc.
    SPELL_PERIODIC Spell_PERIODIC Only the effects that are periodic start with this PREFIX. IE: Successfully casting a DoT only happens once therefore even though the spell is periodic use the SPELL_ prefix. However, the damage is periodic so it will start with SPELL_PERIODIC_.
    SPELL_BUILDING SPELL_BUILDING New in WotLK, assumed to be damage that can affect destructable buildings.
    ENVIRONMENTAL sourceGUID = "0x0000000000000000", sourceName = nil

    As you can see there is no special event category for instant cast spells like you are suggesting so therefore they obey the current event timeline of a cast must successfully complete before it is rolled on the miss table.

    Resource for this post is http://www.wowwiki.com/API_COMBAT_LOG_EVENT look in there if you want to understand the combat log, its all very well drawing out the argument with your assumptions but please just do a bit of googling and you will come across all the answers without me having to explain it again.

    EDIT: You know for the sake of solving this argument, i am quite tempted to download one of these bot programs on my warrior account just to prove that it is a real problem and make people aware so that cheating is going on. I run the risk of a ban on my account, but i currently have 3 with my main not being on the same one as the warrior, so maybe just worth the risk to shut people up!!!
    Last edited by villie; 2014-05-15 at 06:11 PM.

  7. #127
    Quote Originally Posted by villie View Post
    As you can see there is no special event category for instant cast spells like you are suggesting
    I am not suggesting that instant spells have a special event category. This is not necessary. The SPELL_ events are what you see on the client, the server very likely has a slightly different view of that (it might store the proto-events in queues, etc, but it stores additional data attached to these events, and not all queues are even destined for the clients).

    Quote Originally Posted by villie View Post
    Blizzard do it the first way, not possible, they do for the reasons i have already given, as for how the event code is structured, this is how a spell is classified.
    I am sorry, but no, we don't yet know whether they do it the first way, specifically - do the checks after sending SPELL_CAST_SUCCESS for all spells, instant or not.

    I know what the SPELL_ things are, and I know a thing or two on how this works internally as well. I am a dev myself, and I have a natural interest for these kinds of things, so I know what the tables are, what's inside the packets (mostly), what kind of data the server stores and how it ties them together. I have seen the code for several emulators, too.

    No, it is not clear whether Blizzard do the checks after sending SPELL_CAST_SUCCESS for instant-cast spells. There's not enough data.

    If we had the code, we'd know. The sniffs are inconclusive.

    None of that means that HoJ can't be reflected, of course. It might be special cased, for example. Whether it is or it isn't, I don't know, I don't have the data (in this particular case the sniffs *would* help, but I don't have them).

    - - - Updated - - -

    Quote Originally Posted by Illana View Post
    He just explained why doing checks before is more difficult, how dense do you intend to be?
    Do you even understand what we are arguing over? :-)
    Last edited by rda; 2014-05-16 at 06:39 AM.

  8. #128
    I do, it's the order of which the events are received and processed. There is only one logical way to do it without causing unnecessary communication and villie explained it to you and you still refuse to believe it.

  9. #129
    Quote Originally Posted by Illana View Post
    I do, it's the order of which the events are received and processed. There is only one logical way to do it without causing unnecessary communication and villie explained it to you and you still refuse to believe it.
    LOL, OK. What villie says they do actually involves more communication than the other way, just so you know. But it's nice that you understand. :-)

  10. #130
    Quote Originally Posted by rda View Post
    LOL, OK. What villie says they do actually involves more communication than the other way, just so you know. But it's nice that you understand. :-)
    it's about the efficiency of the communication, not the amount of packets sent

    but it's nice to know you understand.

  11. #131
    Quote Originally Posted by Illana View Post
    it's about the efficiency of the communication, not the amount of packets sent

    but it's nice to know you understand.
    Care to elaborate on where is that added efficiency that you are talking about? I'd also love to know what you meant by "without causing unnecessary communication" since apparently that wasn't about the number of packets. :-)
    Last edited by rda; 2014-05-16 at 10:24 AM.

  12. #132
    Wow Pvp is becoming a bigger and bigger joke with each passing patch. Highly geared pre-mades coordinating on Skype are facing off against undergeared random noobs. Blizzard does nothing. Bots are wandering around BGs in abundance. Blizzard does nothing. People are now using interrupt bots for perfect timing and apparently spell reflects now too. Blizzard does nothing. And, lets not forget all of the ddos'ing that goes on in arena and rbgs. And, of course, Blizzard does nothing.

  13. #133
    Quote Originally Posted by rda View Post
    Care to elaborate on where is that added efficiency that you are talking about? I'd also love to know what you meant by "without causing unnecessary communication" since apparently that wasn't about the number of packets. :-)
    checking whether or not a spell has landed or not even if it was cancelled is wasted communication, I think that's the part where you need to understand.

  14. #134
    Quote Originally Posted by Illana View Post
    checking whether or not a spell has landed or not even if it was cancelled is wasted communication, I think that's the part where you need to understand.
    Noone asked to do the checks for canceled spells (LOL, where do you even get these things from). The checks against non-canceled spells happen in all scenarios. There's no way not to do them. And that doesn't involve communication, the communication happens before the checks, the clients send the server what they are trying to do, the server doesn't ask them if a particular spell has landed, it tells them that and the clients obey (and no, not obeying doesn't get you anything). And that's not what we have argued over. :-)

    Really, if you think you are doing a good job hiding your lack of understanding, you are wrong. It is very clear that you only have a vague idea. You didn't even understand what we were talking about.

    Good luck on the Interwebs. You'll need it.
    Last edited by rda; 2014-05-17 at 04:25 AM.

  15. #135
    Quote Originally Posted by rda View Post
    Noone asked to do the checks for canceled spells (LOL, where do you even get these things from). The checks against non-canceled spells happen in all scenarios. There's no way not to do them. And that doesn't involve communication, the communication happens before the checks, the clients send the server what they are trying to do, the server doesn't ask them if a particular spell has landed, it tells them that and the clients obey (and no, not obeying doesn't get you anything). And that's not what we have argued over. :-)

    Really, if you think you are doing a good job hiding your lack of understanding, you are wrong. It is very clear that you only have a vague idea. You didn't even understand what we were talking about.

    Good luck on the Interwebs. You'll need it.
    but checking whether or not a spell is applied before the confirmation on whether or not it is a success is dumb. Server receives packet saying spell has started casting, as Villie said there is no differentiation between instant and cast time spells the server ALSO needs to receive a packet confirming it's success in cast.

    If you make the check on whether or not it's applied in the same packet as the one that told the server it started it's a whole bunch of wasted data as it has to check whether or not it was applied anyway.

    I think it's you who didn't understand anything Villie said.

  16. #136
    Quote Originally Posted by Illana View Post
    but checking whether or not a spell is applied before the confirmation on whether or not it is a success is dumb. Server receives packet saying spell has started casting, as Villie said there is no differentiation between instant and cast time spells the server ALSO needs to receive a packet confirming it's success in cast.

    If you make the check on whether or not it's applied in the same packet as the one that told the server it started it's a whole bunch of wasted data as it has to check whether or not it was applied anyway.

    I think it's you who didn't understand anything Villie said.
    Dear, SPELL_CAST_whatever happen on the client. What happens on the server is different. When you cast an instant cast spell, the client sends the server a packet. It then gets from the server a confirmation and it is at that moment that it adds the SPELL_CAST_whatever event into the log where you can see it. For an instant cast spell, the server already has all the data it needs to determine whether or not the cast was successful. It doesn't have to wait for anything else, it can do the checks right there when it receives the "hey, I cast spell X" packet from the client. It is possible that the server does the checks not at that time, but some time after (so the checks will be done against the new, modified state), and in terms of time after the client receives the confirmation from the server about the "hey, I cast spell X" packet and adds a line to the combat log (which the bot then sees and reacts to), but it is absolutely not a given. We have no data for this. That's what we have been discussing.

    But really, it is taking too much time already. I will leave you with your uninformed arrogance and stubbornness, stemming from the desire to say that you've been right somewhere up the thread and this was a bot.
    Last edited by rda; 2014-05-17 at 06:56 AM.

  17. #137
    So you still don't understand then...

    There's no differentiation between casted spells and instant ones, the only thing that is different is the time in between the spell cast and spell success. The person using the bot will likely have low latency and will recognise the spell cast packet and put up reflect before the spell success.

    The data is there from inference, as Villie suggested. If the code makes the checks there and then, you will get contradictions as there is no instant spell or casted spell category, just spells.

    Also nice bow out just because you've realised you're wrong. Very mature and elegant.

  18. #138
    Quote Originally Posted by Illana View Post
    So you still don't understand then...

    There's no differentiation between casted spells and instant ones, the only thing that is different is the time in between the spell cast and spell success. The person using the bot will likely have low latency and will recognise the spell cast packet and put up reflect before the spell success.

    The data is there from inference, as Villie suggested. If the code makes the checks there and then, you will get contradictions as there is no instant spell or casted spell category, just spells.

    Also nice bow out just because you've realised you're wrong. Very mature and elegant.
    What contradictions????? What? I don't even...

    Quote Originally Posted by Illana View Post
    The person using the bot will likely have low latency and will recognise the spell cast packet and put up reflect before the spell success.
    It doesn't work like that. How many times do I have to explain it. Player X targets player Y and presses HoJ. Client for player X sends the server a packet. The server processes that packet and informs clients for both players (and other players in the area) about that. It's at that time when client for player Y gets to know that player X cast a HoJ on it. Not earlier. The server has a chance to do the checks before everybody else but the caster knows about that cast. Period.
    Last edited by rda; 2014-05-17 at 07:12 AM.

  19. #139
    Quote Originally Posted by rda View Post
    What contradictions????? What? I don't even...



    It doesn't work like that. How many times do I have to explain it. Player X targets player Y and presses HoJ. Client for player X sends the server a packet. The server processes that packet and informs clients for both players (and other players in the area) about that. It's at that time when client for player Y gets to know that player X cast a HoJ on it. Not earlier. The server has a chance to do the checks before everybody else but the caster knows about that cast. Period.
    But it's been clearly explained to you that's not how it works. Do you have selective reading disorder?

    Player X presses HoJ
    Sends packet to server
    Server sends request: did you complete the cast?
    Player X says: yes I did

    The part where it asks if the cast was completed is mandatory for ALL spells as, once again, they are not differentiated from instant and casted.

    Is there any way to make this clearer or should I just give up?

    If the decision that the HoJ lands is done when the packet is sent you could get someone who get's stunned with cloak up and that has NEVER happened.

  20. #140
    Quote Originally Posted by Illana View Post
    But it's been clearly explained to you that's not how it works. Do you have selective reading disorder?

    Player X presses HoJ
    Sends packet to server
    Server sends request: did you complete the cast?
    Player X says: yes I did

    The part where it asks if the cast was completed is mandatory for ALL spells as, once again, they are not differentiated from instant and casted.

    Is there any way to make this clearer or should I just give up?

    If the decision that the HoJ lands is done when the packet is sent you could get someone who get's stunned with cloak up and that has NEVER happened.
    This line doesn't happen:

    Server sends request: did you complete the cast?

    It just doesn't.

    The somewhat similar treatment of instant spells and non-instant spells in the combat log and in some tables that seems to throw you off is a CLIENT-ONLY THING. It DOES NOT MEAN that the server processes these spells equally.

    Cloak is a special case in their code. There's a history behind that spell. Same for vanish and several other spells. If you want to say that HoJ is a similar special case, go ahead, it might be the case, but present some evidence.
    Last edited by rda; 2014-05-17 at 07:38 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •