Ability Delay -- Character Responsiveness (This will make or break SW:TOR)

[Tiron_Raptor]

http://www.youtube.com/watch?v=TzP0xjNLyX4

 

The video is too low res for detailed analysis, but it appears to show the mechanics working perfectly, so far as I can tell.

 

 

 

Demonstrates an interesting UI bug involving the castbar, but the only instance of any delay I'm seeing is on his second use of dark heal, at about 0:07 seconds: there's a palpable delay before it starts playing. Not sure of the cause here, but all the others went off flawless it seemed (except for the castbar not showing up.)

 

Doesn't really appear to be related to a delay problem.

 

 

 

Activates master strike, waits for it to finish. Multi-clicks force wave (or whatever it's called), then multi-clicks the interrupt kick, which doesn't activate until about the second or third click (it's supposed to be non-GCD, so this IS interesting, I'll check riot strike later to see if it does that).

 

Waits for a second, then hits cauterize, then multi-taps the crossed sabers thing next to it, starting right before the GCD ends, and still gets it off immediately at the end of the GCD (Queue off? would explain the spamming, queue off would work well with spamming), mutli-taps first slot, which goes off NEARLY(there's a VERY fractional flash of available on the other buttons, I'd say the queue is off) immediately at the end of the GCD. double-taps the slash-thing(the one that costs focus, not the one that generates, that you start with) almost perfectly after the GCD ends, and it fires immediately. Hits the first slot crossed-sabers again(that sentinel basic slash replacement I think?), multi-taps it starting just before the GCD ends, fires simultaneous with the first click after the GCD ends (Queue is for sure off). starts tapping the focus-using slash again before the GCD ends, and manages to get it off perfectly chained again.

 

Then it gets interesting: he starts spam-clicking riposte mere moments after hitting slash-thing. This confuses the client quite obviously, as it keeps starting the animation each time he clicks. What's really interesting however, is that based on the focus AND on the cooldowns, it appears that it does not fire until the GCD has completed. Riposte is supposed to be a non-GCD ability: that functionality appears to be bugged...possibly server side. At least part of the client thinks it's firing the ability and starts simulating it, but the actual firing doesn't occur until after the GCD ends.

 

He then hits the basic focus-generating attack, then tries to hit slash which he doesn't have the focus for.

 

Verdict: Riposte appears to be bugged and respecting the GCD, in spite of both the icon and the tooltip indicating that it does NOT.

Edited January 4, 2012 by Tiron_Raptor

[Tiron_Raptor]

Seriously? THis thread is already beyond determining whether or not the ability delay exists, the debate now is whether or not bioware intended for it to exist.

 

The argument your having ended in the first post

 

Only if you're so ignorant that you're unwilling to change your mind, even in the face of evidence to the contrary.

 

That is not a reasonable position.

 

No, stop glorifying yourself, your entire analysis is false... it has nothing to do with his keypress but the fact that the first animation had to finish before the next ability could be used...

 

How on earth can you be so dense and fervently defensive, attempting yourself to be a hero of revelation. You haven't even taken the issue seriously enough to read through the evidence or watch the videos listed in the OP you're responding to...

 

 

I am done with you... this is ridiculous,

 

 

You're the one that's defensive. Insulting and attacking me in ways that I've just barely held off flagging you for.

 

I watched about half of the videos initially, but not closely, because on a cursory examination of most of them *I DID NOT SEE ANY DELAY PROBLEM IN EVIDENCE.*

 

That first one I analyzed for example: What I see is the ability successfully firing while the animation for the first is still playing.

 

You're conflating the playing of the animation with the use of the ability, which is NOT the case. On any game since about 2001 or so.

[AlexRose]

http://www.youtube.com/watch?v=TzP0xjNLyX4

 

The video is too low res for detailed analysis, but it appears to show the mechanics working perfectly, so far as I can tell.

 

 

Demonstrates an interesting UI bug involving the castbar, but the only instance of any delay I'm seeing is on his second use of dark heal, at about 0:07 seconds: there's a palpable delay before it starts playing. Not sure of the cause here, but all the others went off flawless it seemed (except for the castbar not showing up.)

 

Doesn't really appear to be related to a delay problem.

 

 

Activates master strike, waits for it to finish. Multi-clicks force wave (or whatever it's called), then multi-clicks the interrupt kick, which doesn't activate until about the second or third click (it's supposed to be non-GCD, so this IS interesting, I'll check riot strike later to see if it does that).

 

Waits for a second, then hits cauterize, then multi-taps the crossed sabers thing next to it, starting right before the GCD ends, and still gets it off immediately at the end of the GCD (Queue off? would explain the spamming, queue off would work well with spamming), mutli-taps first slot, which goes off NEARLY(there's a VERY fractional flash of available on the other buttons, I'd say the queue is off) immediately at the end of the GCD. double-taps the slash-thing(the one that costs focus, not the one that generates, that you start with) almost perfectly after the GCD ends, and it fires immediately. Hits the first slot crossed-sabers again(that sentinel basic slash replacement I think?), multi-taps it starting just before the GCD ends, fires simultaneous with the first click after the GCD ends (Queue is for sure off). starts tapping the focus-using slash again before the GCD ends, and manages to get it off perfectly chained again.

 

Then it gets interesting: he starts spam-clicking riposte mere moments after hitting slash-thing. This confuses the client quite obviously, as it keeps starting the animation each time he clicks. What's really interesting however, is that based on the focus AND on the cooldowns, it appears that it does not fire until the GCD has completed. Riposte is supposed to be a non-GCD ability: that functionality appears to be bugged...possibly server side. At least part of the client thinks it's firing the ability and starts simulating it, but the actual firing doesn't occur until after the GCD ends.

 

He then hits the basic focus-generating attack, then tries to hit slash which he doesn't have the focus for.

 

Verdict: Riposte appears to be bugged and respecting the GCD, in spite of both the icon and the tooltip indicating that it does NOT.

 

Yes but before we can discuss this you should really read this:

http://www.elsewhere.org/pomo/

[Xcore]

Only if you're so ignorant that you're unwilling to change your mind, even in the face of evidence to the contrary.

 

That is not a reasonable position.

 

 

 

 

You're the one that's defensive. Insulting and attacking me in ways that I've just barely held off flagging you for.

 

I watched about half of the videos initially, but not closely, because on a cursory examination of most of them *I DID NOT SEE ANY DELAY PROBLEM IN EVIDENCE.*

 

That first one I analyzed for example: What I see is the ability successfully firing while the animation for the first is still playing.

 

You're conflating the playing of the animation with the use of the ability, which is NOT the case. On any game since about 2001 or so.

 

How do you not comprehend that no-one here is stupid enough to believe that the "Animation" literally shoots out the frostbolt that does the damage?

 

Green: Once again, every time you make this statement or any like statement, you invalidate your entire standpoint and credibility.

 

 

P.S.: The more posts I read of yours the more I am lead to believe that you are a Bioware Developer.

[Tiron_Raptor]

If this were true, then the whole mount-issue wouldn't exist, right? If you can mount (which is just like "casting" an ability) and the animation portion was just cosmetic, then you'd be able to start moving as soon as the cast was completed and not need to wait for the animation to finish. No?

 

The same thing is happening in combat when animations and other movement or abilities collide. Animations may be cosmetic in specific instances, but there are clear examples of where they are part of the problem.

 

As I explained in detail at the bottom of the first page here: http://www.swtor.com/community/showthread.php?p=1162489#post1162489

 

This is a network latency issue. Your client is SIMULATING you getting on your mount at the end of its ESTIMATED castbar, in anticipation of the state of things on the server, in order to avoid an obvious network-latency delay that would be quite jarring.

 

What happens is that somehow, your 'I moved' message generated after you client simulated you on your mount got the server before it thought you were mounted, and it sent back that your mount attempt was cancelled by the movement, which causes the client to abruptly correct its state by 'dismounting' you.

 

In fact, you were never mounted at all, it just LOOKED like you were on your client.

[Xcore]

I should note: (I am mildly comforted by this) -- Well played Mr. Amatangelo

 

http://www.swtor.com/blog/new-year%E2%80%99s-pvp-update

 

 

Combat Gameplay: You’ll see several optimizations come online in January, and we are going to continue to tune this as time goes on.

 

Gabe Amatangelo

Principal Lead PvP, Operations & Flashpoints Designer

[Xcore]

As I explained in detail at the bottom of the first page here: http://www.swtor.com/community/showthread.php?p=1162489#post1162489

 

This is a network latency issue. Your client is SIMULATING you getting on your mount at the end of its ESTIMATED castbar, in anticipation of the state of things on the server, in order to avoid an obvious network-latency delay that would be quite jarring.

 

What happens is that somehow, your 'I moved' message generated after you client simulated you on your mount got the server before it thought you were mounted, and it sent back that your mount attempt was cancelled by the movement, which causes the client to abruptly correct its state by 'dismounting' you.

 

In fact, you were never mounted at all, it just LOOKED like you were on your client.

 

This is true, this is ONE of many flaws, this is still a BIG flaw.

 

 

Castbar completes = Mounted, no "if", "but'", "when", "who" or "how".

[Unruhe]

As I explained in detail at the bottom of the first page here: http://www.swtor.com/community/showthread.php?p=1162489#post1162489

 

This is a network latency issue. Your client is SIMULATING you getting on your mount at the end of its ESTIMATED castbar, in anticipation of the state of things on the server, in order to avoid an obvious network-latency delay that would be quite jarring.

 

What happens is that somehow, your 'I moved' message generated after you client simulated you on your mount got the server before it thought you were mounted, and it sent back that your mount attempt was cancelled by the movement, which causes the client to abruptly correct its state by 'dismounting' you.

 

In fact, you were never mounted at all, it just LOOKED like you were on your client.

 

So, what part of your post explains where this isn't an example of the absolutely atrocious lack of synchronization (also know as a 'delay') between the client and the server?

[MinatureHero]

im not sure is this has been mentioned but i thought it was worth noting.

 

Combat Gameplay: You’ll see several optimizations come online in January, and we are going to continue to tune this as time goes on.

 

i copy'd that from the new years pvp update they had at top of the forum page.

 

there is more info about pvp on their but this was the only relevant part to this thread, not exactly much to go on but at least its something. hopefully this will make the game play more competitive and enjoyable with more improvements to come.

 

edit: lol your post wasnt there a min ago!

Edited January 4, 2012 by MinatureHero

[deathbycanuck]

An intelligent well laid out criticism - well documented to make future changes. 5 stars.

[Radagastimus]

As of today i have played Sith inquisitor and this issue is worse ever there until now at least. Quite frankly for the case of this issue it happens since there is simply too many players on Coriban and world server just cant handle all the players doing all kind of stuff there.

 

Tried to play a bit of my Smuggler on Nar Shadaa and he was just fine. no lags or delays on abilities

 

And the issue is exactly how OP explained it when i play Sith at Coriban. Maybe it is the kind of Jita prob from eve online where that world is just full and there is no limit of players there and therefore it has issues.

[Tiron_Raptor]

How do you not comprehend that no-one here is stupid enough to believe that the "Animation" literally shoots out the frostbolt that does the damage?

...I'm not sure exactly what this means, it doesn't really entirely make sense to me.

 

what I've been saying is that the animation is a cosmetic nicety and nothing more: that it in fact has nothing at all to do with when the ability is used or when the damage is dealt. These things occur on the server, where there are no animations, and what you see is merely your client's representation of what the server is telling it about the state of the game world and all the objects within it.

 

There IS a cosmetic effect where, after the client receives a message from the server indicating a hit and how much damage it did, that the client does not display the damage, enter it into the combat log, or show it on the enemy's health bar immediately. It attempts to wait until the animated bolt hits the target. This effect is actually more easily seen on WoW than on SWTOR.

 

Using an epic flying mount, fly past/away from a caster firing slow bolts. Frostbolts, fireball, arcane missiles, whatever. The slower ones you can actually outrun on a flying mount. What happens? The damage indication is delayed. Even if traveling slower than the bolt(ground epic mount say), you can still get outside the caster's attack range before it catches up. If the bolt catches up quickly enough, the damage will be indicated via flytext, your HP bar, and your combat log at the moment the bolt hits your character. If you continue to outrun it, however, after a reasonably long period of time it will 'time out' and display the damage even though the bolt's still following you. If you then stop, the bolt will catch up and hit you, and your character will animate a hit, but no damage will be dealt.

 

That the server has already calculated and made use of the damage dealt before the bolt hits you becomes apparent in a different situation: if you are killed at sufficient range by a bolt-based spell. Instead of waiting for the bolt to catch up before the damage is dealt and you are killed, you fall down dead immediately and the bolt ends up hitting your corpse, sometimes even causing your character to animate a hit...with their upper body only. This happens because when the server figured the damage, it calculated that you died and sent a message to that effect immediately. Which takes precedence over the client's cosmetic bolt-damage-delay effect.

 

Green: Once again, every time you make this statement or any like statement, you invalidate your entire standpoint and credibility.

 

Only if you're basing your conclusions on your emotions and not on facts, which you wouldn't be doing if you were, in fact, a 'scientist' as you claimed.

 

Are you denying everything I say because you've objectively analyzed it and it's not true, or because you've already reached a conclusion and can't bring yourself, emotionally, to admit that it's incorrect? Or even to countenance any possible suggestion that it might be correct?

 

Either is worthy of a US Congressman, but not actual humans.

 

P.S.: The more posts I read of yours the more I am lead to believe that you are a Bioware Developer.

 

If I was, do you think I'd be posting here anonymously?

 

Do you think you OR this thread would still be here and open? Do you think that I'd let you get away with directly insulting me like that if I worked for the company that has a policy that says you can't do that to anyone?

 

I have to admit I'm slightly flattered, but I'm a computer TECH, not an administrator or a programmer(I couldn't BEGIN to do programming on something like this). I have serious social skills deficiencies that rule out customer service. And I'm only moderately skilled at networking at best.

 

I'm a college student, trying to get a degree to help prove that yes, I do know how to fix your computer. I was building them and fixing them before I started, but that won't get you hired anywhere.

 

Before they got bought by EA, working for Bioware would've fulfilled one of my wildest dreams. Now, I don't think I'd want to. EA has a (deserved) bad reputation for tearing the studios they buy apart by trying to force them to turn out Pap like EA sports has been doing for decades.

 

I am, frankly, not worthy or skilled enough to work there, regardless of the EA situation.

[AlexRose]

I have to admit I'm slightly flattered, but I'm a computer TECH, not an administrator or a programmer(I couldn't BEGIN to do programming on something like this). I have serious social skills deficiencies that rule out customer service. And I'm only moderately skilled at networking at best.

 

Well mate I am a computer programmer and I can tell you that you assume too much. If you dont work for BW you simple cannot know how the client server communication is implemented. You cannot know when the messages are sent, asynchronously, synchronously in relation to events, what events, how is lag correction implemented etc. etc.

I dont know how they programmed this thing but I know that they put too much emphasis on computer animations.

Why? Play it, watch it, read it.

 

Edit:

Or you know what? Give me the code. Then we can have your stile of posts but until then as I said: you assume too much.

Edited January 4, 2012 by AlexRose

[Uhuru]

I should note: (I am mildly comforted by this) -- Well played Mr. Amatangelo

 

http://www.swtor.com/blog/new-year%E2%80%99s-pvp-update

 

 

Combat Gameplay: You’ll see several optimizations come online in January, and we are going to continue to tune this as time goes on.

 

Gabe Amatangelo

Principal Lead PvP, Operations & Flashpoints Designer

 

Whoooot!

 

You made a difference man. Congrats!

 

I for one am looking foreward to this.

[Tiron_Raptor]

So, what part of your post explains where this isn't an example of the absolutely atrocious lack of synchronization (also know as a 'delay') between the client and the server?

 

It's called 'Network Latency'. One of the postulates of Einstein's theory of relativity (which I don't even BEGIN to fully understand, only the most basic parts of it) is that no information can travel faster than a constant he calls "C", which is accepted to be equal to the speed of light in a vacuum (it's slower in other materials. I also have my doubts as to if the measured speed of light in a vacuum actually *IS* C, after that bit with the neutrinos apparently going slightly FTL. Most likely it's some systemic bias nobody's caught but... who knows).

 

This means that no information can reach bioware from your client, or your client from bioware, faster than a beam of light could travel between the two of you. This is an extraordinarily short time over the distances involved, but still measurable.

 

Trick being, you can't actually achieve that speed on the internet. The signals can't actually reach the speed of light, because they have to pass through so many different boxes on the way. They're passed from router to router to router, with no pre-defined path (it's actually designed to automatically route AROUND holes in the network if it can). All this passing about slows the signal down. The signals also can only travel a certain distance through whatever medium they're in before they become too degraded to be received, so it has to be intercepted and boosted occasionally.

 

Even with this, the total, round trip response time generally ends up under 200 milliseconds, 0.2 of a second, on most connections. These days, a round trip response time of 20 milliseconds is not unheard of, and under 100MS (just 0.1 of a second) is not unusual.

 

If the travel time was perfectly predictable it could be compensated for: The client would know that it took X amount of time for the server to receive the signal, and that it should receive the success signal back from the server X milliseconds after that timer ends, and compensate accordingly.

 

Unfortunately, the nature of the network makes that impossible. Signal travel times are NOT predictable nor stable: they're changing constantly, based upon innumerable variables. Which of the almost infinite possible routes did it use this time. How long did it take each router along the way to process it and pass it on. How long did it sit in a buffer waiting to be sent down the line to the next router.

 

This makes it all but impossible to perfectly synchronize the client and the server: even if you managed it at one point by correctly predicting the network latency, it'd shift and you'd end up wrong again, quite possibly on the very next signal sent. It simply isn't physically possible to have perfect, synchronized communication between two machines at that sort of distance.

 

And mitigating it with extra prediction has its own flaws: the existing limited prediction is already what's causing you to appear to mount and then dismount. If the prediction is increased, that sort of error will get WORSE, not better. And prediction is the only way, short of someone developing a relativity-violating instantaneous communications mechanism, to try to improve the synchronization.

 

There are two further alternatives:

 

Stop trying to predict things, and have a visible delay equal to your network latency on EVERYTHING you do.

 

Let the client authoritatively decide everything, and deal with all the hacks that result from trusting a machine that's out of your control.

[Uhuru]

Well mate I am a computer programmer and I can tell you that you assume too much. If you dont work for BW you simple cannot know how the client server communication is implemented. You cannot know when the messages are sent, asynchronously, synchronously in relation to events, what events, how is lag correction implemented etc. etc.

I dont know how they programmed this thing but I know that they put too much emphasis on computer animations.

Why? Play it, watch it, read it.

 

Edit:

Or you know what? Give me the code. Then we can have your stile of posts. But as I said: you assume too much.

 

In your profesional opinion then is the ability delay problem something they can fix by patching. I am generally an optimistic person - should I be optimistic this can be fixed, or at the least improved? Thanks,

[Chaosmagistrate]

As I explained in detail at the bottom of the first page here: http://www.swtor.com/community/showthread.php?p=1162489#post1162489

 

This is a network latency issue. Your client is SIMULATING you getting on your mount at the end of its ESTIMATED castbar, in anticipation of the state of things on the server, in order to avoid an obvious network-latency delay that would be quite jarring.

 

What happens is that somehow, your 'I moved' message generated after you client simulated you on your mount got the server before it thought you were mounted, and it sent back that your mount attempt was cancelled by the movement, which causes the client to abruptly correct its state by 'dismounting' you.

 

In fact, you were never mounted at all, it just LOOKED like you were on your client.

 

You sir, or madam, but you seem to be more like a sir, speak with intelligence, and at least some understanding of network latency and client-server interaction.

 

But not all IT/network infrastructure is the same, nor are they utilized in the same manner.

 

From the way you speak of network latency, I have to draw the conclusion, you have never played WoW, or at least not between Season 1 and Season 3, which was essentialy the Burning Crusade, and if you did, you did not play in a Server first PvE or a 2300+ rated Arena squad. And if you did, you only played a Warrior.

 

All other classes at the time had cast-time abilitie and channeled abilities.

 

Why do I draw this conclusion? Because anyone who played a mage, as it mainly started from mages, and then spread to all other classes, was a very special mod, which I no lonber remember the exact name, which evovled into SorchMod, and was then in recent additions put into other mods. For the record, my mind keeps trying to say CrystalMod.

 

The key component of ScorchMod was the ability Scorch, in the Fire tree for Mages. It had a 1.5s cast. But it's uniqueness at the time was that it was the fastest fire mage spell and was essential to the Fire tree DPS. It's key component was to apply a debuff on a target +2% fire damage and stacked five times. So it was important for fire mages to get this debuff as quickly as possible. However, the GCD, also known as global cooldown was 1.5s, so most players pressed the spell, and waited for the cast bar which showed 1.5s before performing Scorch again. Because the client wanted to wait for confirmation from the server that the cast had in fact been performed server side.

 

The geniuses behind ScorchMod discovered that the server-client information flow is one-way when it comes to spellcasting. They discovered that you could in fact "clip" your cast bar. In fact, you could start casting Scorch before your cast bar finished. Client side, it would look like you were attempting to cast the spell, and then just as your hand would ignite on fire, thus signaling the end of the cast bar, you could in fact add a nifty macro:

 

/stopspellcasting

/cast Scorch

 

This would tell the server to interrupt your current cast. However, at the time the server would already have casted the spell, so in fact /stopspellcasting was way to interrupt the spellcast client side.

 

ScorchMod's predecessor was simple castbar mod, which did some very basic time calculations using you latency, and modifying your cast bar with an approximation when you could "clip" your current cast. Thus your cast bar would look like this.

 

[||||____1.43sl 0.07s]

 

What this allowed mages, and all casters was to start their next spell anywhere between 1.44 and 1.5s.

 

There are reams of documentation, probably not as much now that NurfedUI and alot of those forums have gone the way of the dodo, that show how important this mod became. It literally gave guilds striving for World firsts increased throughput across the board for their DPS, healers, and tanks.

 

That is why so many players from WoW and Warhammer remember the mount thing. Because you could in fact clip your mount cast(1.5s), and mount at 1.37s, with good latency, and your character would already be moving at 100% speed, while client side your chracter is still walking. Never did it put you on your mount, then dismount you telling you you were moving, like TOR does.

 

It basically went like this

 

Keyboard: Begin cast (1.5s)

Client: Send cast to server

1.45s of cast bar later, but in reality due to reaction, lag, is more like 1.55s.

Server: Cast was finished

Keyboard: Forward key(W)

Client: start "riding" forward while character model is still on ground.

Server: tell Client cast was finished

Client: update graphics(you are now on a mount)

 

I know there is more to it than just that, but for layman's terms, that was the assumptions made by the mod's creators, and the rampant discussions on EJ forums. Even if they were incredibly wrong, they designed a mod that harnessed this disconnect between the client and server. In the later years, WoW introduced the client ability queue, which rendered ScorchMod obselete, as you could queue your spells and not have to gamble at accidently "clipping" your spells too early.

 

Just to be fair, it's not that many gamers want TOR to be WoW, but this aspect of combat is a miss by Bioware, and a success by WoW.

 

Bioware may be doing something different, but it does not even come close to the smoothness of combat that WoW and Warhammer have. See my example on Charge/Intercept and Force Leap.

 

As a disclaimer, I am not taking a shot at you or your credentials. The fact that this is your field is fair. However some of my undergrad did involve network protocols and etc. Was definitely not my favourite subjects.

 

As for my understanding of a TBC fire mage: I played a mage for all of TBC as my main. I played every other class as well, because I had access to other people's accounts to help them get loot. I was in a Server 2nd/3rd guild. I finished S1 at 2123, and S2 at 2325, which were IMHO the best seasons. And yes I am a nerd. I made it my business to know how to squeeze every drop of DPS and every advantage I could get. I can tell you straight up with 100% confidence that in WoW, I could clip all my casts and channels without worrying about getting screwed by the GCD, by animations finishing. Blizzard got that right. We won't delve into what they got wrong.

[AlexRose]

In your profesional opinion then is the ability delay problem something they can fix by patching. I am generally an optimistic person - should I be optimistic this can be fixed, or at the least improved? Thanks,

 

Lol. I am not all knowing like our beloved Tiron_Raptor. So sadly my answer is pretty simple: I dont know but I suspect a simple patch cannot do it.

I am sure they will try to improve it tho.

[Tiron_Raptor]

Well mate I am a computer programmer and I can tell you that you assume too much. If you dont work for BW you simple cannot know how the client server communication is implemented. You cannot know when the messages are sent, asynchronously, synchronously in relation to events, what events, how is lag correction implemented etc. etc.

I dont know how they programmed this thing but I know that they put too much emphasis on computer animations.

Why? Play it, watch it, read it.

 

Edit:

Or you know what? Give me the code. Then we can have your stile of posts but until then as I said: you assume too much.

 

I've been playing internet games for nearly 13 years. I've done a lot of reading, testing, and studies of my own, and while the details of how they handle it DO make a difference (one I'm not speculating about), some of the basics remain the same no matter how you implement it, simply due to the laws of physics and the nature of how the games are made.

 

I've seen the effects of latency-induced client-server desynchronization firsthand on many occasions. It was part of the reason I was a terrible dogfighter on BF1942 and Desert Combat: I kept aiming at where it looked like they were, and wondering why they wouldn't die when I appeared to hit them over and over: I was missing behind them according to the server, and actually needed to lead them slightly more, appearing to miss in front of them, in order to compensate for the latency and actually hit them.

 

Knowing about that from BF1942, when the SWG: Jump to Lightspeed beta got going, I then applied it: JTL in the beta had a perfectly accurate lead indicator: it showed exactly where you needed to aim in order to hit the target. Except for network latency. This meant that at very high transversal rates, you would be appearing to hit the target and doing no damage.

 

I quickly made the connection with my problems on BF1942 and started leading them a bit more, and started hitting things anyway. I learned to differentiate between the clients 'You hit! I think...' sound and the 'You did damage!' sound it only played upon getting a success message from the server. Nobody else figured it out so far as I could tell, not even the devs. Posts about ships being invulnerable top and bottom were rampant, and it was an issue the devs were seriously investigation (in a tight turning fight, they'd roll up on their wing, presenting the top of their ship to you as they turned across in front of you).

 

I remember one time, going to Tattooine space, and it being just filled with people camping the Hutt fighter respawns I was after. When one would respawn, I would watch as it was surrounded by a web of blaster fire, few if any of them appearing to hit it. I would engage myself, and get credit for the kill every single time(which was based on who did the most damage on SWG), no matter how long it took me to get on the target. I even managed to disable one of the devs in the middle of a massive furball when they called out all the rebels on the server, while everyone else appeared to just be missing them all.

 

Eventually I got tired of it, and posted on the forums explaining what it was, that it was the network latency causing it, and how you could work around it by leading a bit more...

 

And they responded by making the lead indicator not be exact. It merely indicated the direction, but was way out in front of the actual point you needed to fire at. This is the version that went into live.

 

I later used this knowledge again in a discussion on the WoW forums where someone was complaining about some the latency effects needing fixed...and a blue responded more or less saying that it was an excellent summary and dead on.

 

This isn't anything new for me.

 

Edit:

I'll add that yes, I played from seasons 1 to 3, at that point PvP was the only thing I had going. I *DID* in fact play a warrior, and no I wasn't on a top team...in large part because I was doing arenas only with my friends...and mostly with my father.

 

I had a mage alt...a frost mage alt. I forget at what point I leveled her.

 

I do recall hearing about the /stopcasting thing but never bothered myself. Always seemed like a lot of work for a pointless tiny miniscule little bit of optimization, that also had the effect of making such optimization de-facto mandatory in order to be competitive, which I've never liked. There's a difference between skill and having the right macro.

Edited January 5, 2012 by Tiron_Raptor

[Thrage]

The mod in question is now known as "Quartz," and is nearly essential for any serious endgame raider, mage or otherwise.

[Khoranth]

In your profesional opinion then is the ability delay problem something they can fix by patching. I am generally an optimistic person - should I be optimistic this can be fixed, or at the least improved? Thanks,

 

 

Anything can be fixed, the real question is do they want to fix it?

 

We have seen statements from bioware, inside of this thread, that indicate that bioware wants players to enjoy the animations and feel "epic"

 

Giving instant abilities and cast bars, GCD timers and off gcd abilities precedence over animations means clipping animations.

 

So let me re-phrase: the question then becomes "how will they fix the problem?"

 

Bioware can either allow for animation clipping for crisp combat controls.

 

OR bioware can give animations priority and re-work or remove cast bars timers and ESPECIALLY off GCD abilities and instants. Oh and replace the haste stat, and haste abilities that increase casting time.

 

I am sure they will fix it, they aren't morons, but the playerbase, their customers, need answers on the direction they plan to take. Because bioware cannot have both, not without completely re-creating the entire combat system, and that obviously is not an option.

[sleepingferret]

No but your comment sure is.

 

This game reacts no different than games like LoTRO and others. If you like WoW, which btw is a dumbed down version of most combat systems, then too bad. This isn't WoW and I personally do not have problems with the combat system.

 

As a Lifetime LOTRO subscriber, I can tell you that LOTRO has better responsiveness than TOR. WoW still has the best of all the MMO's, but current responsiveness of TOR is just shameful, in fact even in just PvE scenarios I've lost fights because it.

 

Fights I should have won, but since I couldn't get an interrupt off...I got slammed in the face, and with my medpack already on cooldown, well I didn't have the health to win.

[Verdan]

I fully agree that combat is non responsive - for 2 reasons.

 

1- the point of the OP is noted and accurate, and in addition to his examples add one recurring one of my own, that when casting CC's, my own companion will repeatedly break the CC because my action is staggered in time between pressing the key and being implemented. Visually, there's a lag between me hitting the key and CC affect, AND there's no companion hits being shown at the time I hit the key, but only after a clunky pause do I see the companion fire at the same time as my CC fires... The delay is palpable and happens regularly. The same thing is seen in heroics and Flashpoints with other players instead of companions.

 

2- the operation of skill icons is the most clunky, laggy, and nonsensical I've ever played. Someone used the example of animations cutting off for the latest skill firing, yes, thats how it should be....

 

...The press of the key needs to show almost instantaneous (perception) action by the avatar. Skills should be of two types, some instant fire, and some having an induction (blue bar). Those that are instant should show live status when ready to fire, when fired should reflect on the screen as fired instantly, and the moment an avatar is capable to take another action, every icon/skill actionable should light up as ready. What we have instead is a skill is fired, that skill looks like it has started a CD timer, and skills become available seemingly at different durations dependent on the last skill. It's really unintuitive, and leaves me thinking that I may have gotten 3 skills off when I really had the opportunity to get 5 off. What was the odd and irregular timing? Was I waiting different times to allow diff skill animations of diff animation durations time to play out?

 

I really dislike the gameplay related to skill timing and related exception and outcomes. A 2 out of 10 to be generous.

 

Neither of the above problems were present in Lotro, and I was very satisfied with the interaction and timing of player, keyboard, skills, and resulting actions. CC, taunts, nukes... Worked great. In Lotro, you could tell that the client was reacting to key punches with animations, sending data to the server as animations were already playing out on the client. Here, it seems, to maybe give that player-to-player visual interaction Bioware talks about, the data seems to be sent to the server to trigger the animation, and so we have delay. That's bad combat gameplay. Each player doesn't need to see the same thing, each player can see a client-generated action that may not be identical on each players screen, as each client responds immediately to their player's keystroke and the latest server info available. The quicker the server can get validating damage and state info back to clients the better obviously, but a cc on one client should travel 1 way to server then to other player's clients in a straight line, than what appears to be client-server loops before going to other player's clients.

Edited January 5, 2012 by Verdan

[astronaute]

You sir, or madam, but you seem to be more like a sir, speak with intelligence, and at least some understanding of network latency and client-server interaction.

 

But not all IT/network infrastructure is the same, nor are they utilized in the same manner.

 

From the way you speak of network latency, I have to draw the conclusion, you have never played WoW, or at least not between Season 1 and Season 3, which was essentialy the Burning Crusade, and if you did, you did not play in a Server first PvE or a 2300+ rated Arena squad. And if you did, you only played a Warrior.

 

All other classes at the time had cast-time abilitie and channeled abilities.

 

Why do I draw this conclusion? Because anyone who played a mage, as it mainly started from mages, and then spread to all other classes, was a very special mod, which I no lonber remember the exact name, which evovled into SorchMod, and was then in recent additions put into other mods. For the record, my mind keeps trying to say CrystalMod.

 

The key component of ScorchMod was the ability Scorch, in the Fire tree for Mages. It had a 1.5s cast. But it's uniqueness at the time was that it was the fastest fire mage spell and was essential to the Fire tree DPS. It's key component was to apply a debuff on a target +2% fire damage and stacked five times. So it was important for fire mages to get this debuff as quickly as possible. However, the GCD, also known as global cooldown was 1.5s, so most players pressed the spell, and waited for the cast bar which showed 1.5s before performing Scorch again. Because the client wanted to wait for confirmation from the server that the cast had in fact been performed server side.

 

The geniuses behind ScorchMod discovered that the server-client information flow is one-way when it comes to spellcasting. They discovered that you could in fact "clip" your cast bar. In fact, you could start casting Scorch before your cast bar finished. Client side, it would look like you were attempting to cast the spell, and then just as your hand would ignite on fire, thus signaling the end of the cast bar, you could in fact add a nifty macro:

 

/stopspellcasting

/cast Scorch

 

This would tell the server to interrupt your current cast. However, at the time the server would already have casted the spell, so in fact /stopspellcasting was way to interrupt the spellcast client side.

 

ScorchMod's predecessor was simple castbar mod, which did some very basic time calculations using you latency, and modifying your cast bar with an approximation when you could "clip" your current cast. Thus your cast bar would look like this.

 

[||||____1.43sl 0.07s]

 

What this allowed mages, and all casters was to start their next spell anywhere between 1.44 and 1.5s.

 

There are reams of documentation, probably not as much now that NurfedUI and alot of those forums have gone the way of the dodo, that show how important this mod became. It literally gave guilds striving for World firsts increased throughput across the board for their DPS, healers, and tanks.

 

That is why so many players from WoW and Warhammer remember the mount thing. Because you could in fact clip your mount cast(1.5s), and mount at 1.37s, with good latency, and your character would already be moving at 100% speed, while client side your chracter is still walking. Never did it put you on your mount, then dismount you telling you you were moving, like TOR does.

 

It basically went like this

 

Keyboard: Begin cast (1.5s)

Client: Send cast to server

1.45s of cast bar later, but in reality due to reaction, lag, is more like 1.55s.

Server: Cast was finished

Keyboard: Forward key(W)

Client: start "riding" forward while character model is still on ground.

Server: tell Client cast was finished

Client: update graphics(you are now on a mount)

 

I know there is more to it than just that, but for layman's terms, that was the assumptions made by the mod's creators, and the rampant discussions on EJ forums. Even if they were incredibly wrong, they designed a mod that harnessed this disconnect between the client and server. In the later years, WoW introduced the client ability queue, which rendered ScorchMod obselete, as you could queue your spells and not have to gamble at accidently "clipping" your spells too early.

 

Just to be fair, it's not that many gamers want TOR to be WoW, but this aspect of combat is a miss by Bioware, and a success by WoW.

 

Bioware may be doing something different, but it does not even come close to the smoothness of combat that WoW and Warhammer have. See my example on Charge/Intercept and Force Leap.

 

As a disclaimer, I am not taking a shot at you or your credentials. The fact that this is your field is fair. However some of my undergrad did involve network protocols and etc. Was definitely not my favourite subjects.

 

As for my understanding of a TBC fire mage: I played a mage for all of TBC as my main. I played every other class as well, because I had access to other people's accounts to help them get loot. I was in a Server 2nd/3rd guild. I finished S1 at 2123, and S2 at 2325, which were IMHO the best seasons. And yes I am a nerd. I made it my business to know how to squeeze every drop of DPS and every advantage I could get. I can tell you straight up with 100% confidence that in WoW, I could clip all my casts and channels without worrying about getting screwed by the GCD, by animations finishing. Blizzard got that right. We won't delve into what they got wrong.

 

Thank you sir, I was just about to tell something similar.

In WoW the abilities are almost flawless and never too late like in SWTOR. If WoW can do it, SWTOR*should be able to do it if they had good programmers. We will see that in few days or weeks at most.

 

I think maybe we are doomed because of their "Hero" engine thing, maybe this is some kind of internal limitation that is not easy to fix.

 

Honestly, I'm already pretty bored with overall game responsiveness that I don't even notice other game breaking bugs (it's that bad). If they don't to something really fast, It'll soon be too much for me unfortunately.

[Xcore]

...I'm not sure exactly what this means, it doesn't really entirely make sense to me.

 

what I've been saying is that the animation is a cosmetic nicety and nothing more: that it in fact has nothing at all to do with when the ability is used or when the damage is dealt. These things occur on the server, where there are no animations, and what you see is merely your client's representation of what the server is telling it about the state of the game world and all the objects within it.

 

You're incredibly dense and continuously arguing against established facts. If you are unable to catch the meaning behind my quoted post, I cannot (will not) help you.

 

 

Continue with your argument of network (Client/Server Communication) delay, discounting all the other factors that play a role.

 

Continue believing that in fact, there is no real "delay" at all

 

etc.

 

 

Good day sir.