Page 7 of 9 FirstFirst ...
5
6
7
8
9
LastLast
  1. #121
    Deleted
    Instant reflect is no longer a thing. Not even harm macro can do the job, since they added some delay to spell reflect.

  2. #122
    The Patient
    10+ Year Old Account
    Join Date
    Jan 2010
    Location
    London
    Posts
    305
    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.

  3. #123
    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.

  4. #124
    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.

  5. #125
    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. :-)

  6. #126
    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.

  7. #127
    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.

  8. #128
    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.

  9. #129
    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.

  10. #130
    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.

  11. #131
    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.

  12. #132
    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.

  13. #133
    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.

  14. #134
    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.

  15. #135
    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.

  16. #136
    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.

  17. #137
    and you know that because?

  18. #138
    Quote Originally Posted by Illana View Post
    and you know that because?
    Know what? About cloak being special case or about packets or server-side processing or what?

  19. #139
    The Patient
    10+ Year Old Account
    Join Date
    Jan 2010
    Location
    London
    Posts
    305
    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 just can't do this, I causes to many problems, here's another example of why.

    Bearing in mind we have agreed that cast time spells and instant spells are classified as the same.

    Player X casts chaos bolt on player Y, cast time 4s. Server registers start of cast, rolls for miss, as you suggest@0.1sec into the cast as player X has 100ms, server registers hit and waits for cast success. Player Y @3.5s into the cast puts up ams, before the cast has finished and we know from game mechanics it will be absorbed, so therefore ANOTHER roll for miss must occur AFTER success.

    My question to you is what's the point in this scenario of rolling before the spell registers success as the hit data is wrong when success occurs and how does the server know that the hit data is incorrect without rolling again?

  20. #140
    Quote Originally Posted by villie View Post
    But it just can't do this, I causes to many problems, here's another example of why.

    Bearing in mind we have agreed that cast time spells and instant spells are classified as the same.

    Player X casts chaos bolt on player Y, cast time 4s. Server registers start of cast, rolls for miss, as you suggest@0.1sec into the cast as player X has 100ms, server registers hit and waits for cast success. Player Y @3.5s into the cast puts up ams, before the cast has finished and we know from game mechanics it will be absorbed, so therefore ANOTHER roll for miss must occur AFTER success.

    My question to you is what's the point in this scenario of rolling before the spell registers success as the hit data is wrong when success occurs and how does the server know that the hit data is incorrect without rolling again?
    No, no, no, I am not saying that the server checks whether chaos bolt will land at the moment it starts casting. That spell has a cast time, the server knows it, so, of course, it will do the checks for that spell at the cast END, not start. That's what the semantics of a spell with the cast time are, too.

    But in the case of an instant-cast spell, the server knows that there is no cast time, and it can do the checks for that spell the instant it gets the "I cast a spell" packet.

    That instant-cast spells and spells with non-zero cast time are stored in the same tables, generate similar events and produce similar entries in the combat log mean nothing. All these things are client-only. The server view of what's going on is different.
    Last edited by rda; 2014-05-17 at 07:53 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
  •