Hi,
ATM I am unable to buy xiv due to halt in sales, but I have been reading and watching streams in the last days.
Something I have been wondering:
This happens in many other MMOs but WoW its the best case example.
Link: http://wowhats.wordpress.com/2010/03/07/lag-and-world-of-warcraft/
I will paste the important part:
Quote:
The /stopcasting story
As we have seen, the client and server are separated by a time delay (“lagâ€), which can only be measured by timing how long it takes for a packet of data to travel from the client, to the server, and back again. This is the “latency†figure reported in WoW. This figure is significant because many actions depend on the client asking the server to do something (like cast a spell), the server receiving and confirming the instruction, and then both client and server beginning the action. When the server completes the action, it lets the client know and – prior to patch 2.3 - the client would then and only then enable the sending of more instructions to the server. Before that the player would just have to sit and watch their cast bar fill up.
So prior to patch 2.3, a spellcasting timeline for a spell that takes 2 seconds to cast (2000ms) would look like this, assuming 0 reaction time and 200ms latency:
[img]http://wowhats.files.wordpress.com/2010/03/clientservercasting.png[/img]
As you can see, with this model, a player’s full lag is inserted before every new spell cast. A 2-second cast with 200ms latency was effectively a 2.2-second cast.
However, cunning players realised that if they told the client to stop their spellcast after the point where that instruction would no longer reach the server in time to actually stop the cast, they could then make sure that the instruction to cast the next spell reached the server as soon as possible. This was risky but if you could pull it off it eliminated the effect of latency.
[img]http://wowhats.files.wordpress.com/2010/03/clientservercasting-stop.png[/img]
So you (hopefully) see, under this model people were saving time by “tricking†the client and server into behaviour that contradicted each other. After the initial cast (where latency could not be entirely eliminated), in theory it was possible to make the server chain-cast – at the risk of accidentally cancelling your spells if you timed it wrongly. Obviously this was all a bit ticklish and unpleasant.
As we have seen, the client and server are separated by a time delay (“lagâ€), which can only be measured by timing how long it takes for a packet of data to travel from the client, to the server, and back again. This is the “latency†figure reported in WoW. This figure is significant because many actions depend on the client asking the server to do something (like cast a spell), the server receiving and confirming the instruction, and then both client and server beginning the action. When the server completes the action, it lets the client know and – prior to patch 2.3 - the client would then and only then enable the sending of more instructions to the server. Before that the player would just have to sit and watch their cast bar fill up.
So prior to patch 2.3, a spellcasting timeline for a spell that takes 2 seconds to cast (2000ms) would look like this, assuming 0 reaction time and 200ms latency:
[img]http://wowhats.files.wordpress.com/2010/03/clientservercasting.png[/img]
As you can see, with this model, a player’s full lag is inserted before every new spell cast. A 2-second cast with 200ms latency was effectively a 2.2-second cast.
However, cunning players realised that if they told the client to stop their spellcast after the point where that instruction would no longer reach the server in time to actually stop the cast, they could then make sure that the instruction to cast the next spell reached the server as soon as possible. This was risky but if you could pull it off it eliminated the effect of latency.
[img]http://wowhats.files.wordpress.com/2010/03/clientservercasting-stop.png[/img]
So you (hopefully) see, under this model people were saving time by “tricking†the client and server into behaviour that contradicted each other. After the initial cast (where latency could not be entirely eliminated), in theory it was possible to make the server chain-cast – at the risk of accidentally cancelling your spells if you timed it wrongly. Obviously this was all a bit ticklish and unpleasant.
NOW, in Realm Reborn most spells are not even longer than the GCD, which makes this pointless.
However, end game spells have cast times of 3.5 as is the case of Thunder III.
I HAVE READ in some places people saying "you can move before the spells finish and it still goes off" which means RR doesnt have a dynamic spell system, like WoW implemented in patch 2.3:
Quote:
Patch 2.3 and the spell queue
In patch 2.3, a system was added whereby the client would no longer ever prevent the player from sending new casting instructions to the server (except for during a “hard†1000ms lock after each cast is begun). Instead, you can send the instructions at any time and, if there is not much time left on the spell cast, the server will “queue†the next instruction instead of rejecting it. This duplicates the behaviour of the stopcasting macros without requiring the same sort of split-second precision timing and without any of the risk.
Nowadays, if you are half way through a spell and you press the button to cast another spell, you won’t get the “Another action is in progress†message until after the client has sent the instruction to the server and the server has said “hold on yet, I’m not finished!“. And if the spell you are casting is nearly complete when you press the button (the window of opportunity is thought to be about 300ms) then the server will say “thanks, I’ll cast that next†and the client will not give you an error at all.
So using the spell queue it is in theory possible to eliminate most of the effects of “network“ latency. We’ll talk about exactly how that works in part three, where we’ll also deal with the issue of reaction times.
In patch 2.3, a system was added whereby the client would no longer ever prevent the player from sending new casting instructions to the server (except for during a “hard†1000ms lock after each cast is begun). Instead, you can send the instructions at any time and, if there is not much time left on the spell cast, the server will “queue†the next instruction instead of rejecting it. This duplicates the behaviour of the stopcasting macros without requiring the same sort of split-second precision timing and without any of the risk.
Nowadays, if you are half way through a spell and you press the button to cast another spell, you won’t get the “Another action is in progress†message until after the client has sent the instruction to the server and the server has said “hold on yet, I’m not finished!“. And if the spell you are casting is nearly complete when you press the button (the window of opportunity is thought to be about 300ms) then the server will say “thanks, I’ll cast that next†and the client will not give you an error at all.
So using the spell queue it is in theory possible to eliminate most of the effects of “network“ latency. We’ll talk about exactly how that works in part three, where we’ll also deal with the issue of reaction times.
IN THIS CASE ! we have a wonderful way to increase DPS (or Healing... which I never do :P) significantly!
Now, I did a little research and could not find a cancel cast macro command in RR... which sucks... but is something we can work around.
If this is the case (not having a macro) then I will use keyboard macro programs to issue a W command before each cast, which works the same way. OR DO IT MANUALLY, which would be a pain in the a** but doable nonetheless.
NOW, can someone CONFIRM that you can MOVE before the cast bar reachs completion and STILL gets the spell to fire off? A lvl 50 THM would be able to test this easily!
"If you're using a controller, the triangle button is actually used to cancel actions."
using a controller maybe an option
EDIT
I will paste this here, since a lot of people might say this is trivial:
it might not seem like a big difference but it is.
when I played wow, using this stuff would while lvling would make a mob go down 40% faster...
also, watch this, might make you change your mind:
http://www.youtube.com/watch?v=VgDjG_0ecTI
ALSO take into account HASTE which lowers your gcd = more dps, the amount of haste to lower 0.2 is huge...
removing a 0.2 of 3.5 casting just be using a macro is quite a lot of dps
Edited, Sep 2nd 2013 5:05am by Katriss
Edited, Sep 2nd 2013 5:46am by Katriss
Edited, Sep 2nd 2013 5:53am by Katriss
Edited, Sep 2nd 2013 5:58am by Katriss
