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

[AlacrityFitzhugh]

So, if Bioware has acknowledged that they are looking into it, why continue blathering? Bored at school/work?

[Tiron_Raptor]

You can't make the claim that "the bits that are delayed are non-critical" at all. The grenade is a perfect example of it being critical. The ability is not triggered until the animation of the previous ability is completed.

 

Also my Smuggler, Trinket -> Cover -> Knockback issue displays this as well. This is within part of the feature coding, the way the game handles Animation/Ability Priorities.

 

Actually, with the grenade, it APPEARS that it's not activating until the previous animation's ability is completed...but frankly, with the short time periods involved and only one example to go off of, it's not readily apparent if the damage/buff trigger was delayed by the animation, if it actually DID take effect before the client even showed it taking effect, or if it was simply a coincidence that it showed up at the start of the anim because of some very lucky timing.

 

One thing that I noted when watching it is that the second rakghoul never takes a single step towards the player throughout the entire video. You can tell when he aggros, because he rears up, but he doesn't take a step until after he gets blown into the air by the grenade anim.

 

Unfortunately the timing's so tight that I can't readily tell if he got frozen in place before or after the grenade anim started: he clearly rears up before the grenade anim begins, but the other 'ghouls don't start moving until shortly after the grenade anim has started. He rears up just a tiny bit after the charged burst finishes its cast time, which is also right when the grenade gets activated...so I also can't tell if he got chain aggro from the burst or direct from the grenade. It's almost precisely simultaneous with the burst's first damage tick, so I'm inclined to think probably chain aggro... but I can't be absolutely sure.

 

That's the thing. Too many variables to be 100% sure about precisely what is actually happening, because there's several alternate possibilities that can't be told apart with that vid.

 

As for this smuggler cover trinket thing...I'm not sure what you mean there either.

 

The six issues or more discussed are all cause and symptom of what he is experiencing. There is no one single item that will define what he means.

 

Thus a thread called on the overall issue of Responsiveness... the problem you're creating is separating the issues and attempting to pinpoint key and exact causes. This is up to the Dev Team, the best we can do is point towards the individual problems. We can attempt to diagnose but without Bioware's input we can simply not know the exact causes. My problem is that you claim that you can without any idea of the coding issues involved. Every single proposition you make is at best, guesswork through observation.

 

In fact no-one really has any idea of the details on the Engine/Feature/Interaction Coding at all... besides Bioware, or the Engine Devs that they bought it from...

 

 

Its actually up to Bioware to fix it, not you or I... and as far as providing "feedback" there is plenty in both the OP as well as throughout 5 threads now. I believe they understand the problem quite well at this point... from every angle.

 

P.S.: You have to remember that basically until this thread, it was more like "Um... something is clunky"... /cancelsubscription.

 

Without guesswork through observation, you would not be playing SWTOR right now, because almost none of the technologies used to make it, run it, or that it builds upon would've ever been invented. Practically every bit of knowledge you've learned throughout your life ultimately came out of some guy making a guess based on something he saw.

 

Observation, in fact, is the only way to be SURE of most things in this world.

 

Any help we give them in figuring it out speeds up the process of getting it all fixed.

 

Cramming them all together under one, not entirely accurate banner doesn't help with that. It makes it so that when someone says they're having problems, you can't be sure what problem they're having. It may not actually be all of them! It might only really be one or two. It might be something entirely new that hasn't been reported on yet. You don't know, because they said 'it's not responsive'. How does Bioware find out what's wrong from that?

 

It would, in fact, be far better if each individual problem making up your 'greater whole' had its own thread with separate documentation and information about that bug only.

 

Right now, I have no idea which of those videos in the OP is supposed to reference which problem, and it isn't always apparent from watching them.

 

When I cast an ability, it takes 0.5 to 1 seconds after I hit the button before the animation starts and it casts the ability.

 

It works the same way with my moves that have a cast time, there is a delay between when the cast bar ends, and when the ability starts.

 

Its impossible to PvP like this.

 

As I've said many times, you've already cast the ability before you see it on your screen. Yes it's delayed, but that delay so far as I can tell only affects what you see, not what you can do.

 

The fact that it takes so long to show up is irritating, yes, but shouldn't be impairing your ability to PvP, for the most part.

 

The bugged abilities or the screwed up action queue, on the other hand, might.

 

Edit: Wish I had something on a cast time so I could experiment with that delay.

Edited January 6, 2012 by Tiron_Raptor

[Xcore]

Actually, with the grenade, it APPEARS that it's not activating until the previous animation's ability is completed...but frankly, with the short time periods involved and only one example to go off of, it's not readily apparent if the damage/buff trigger was delayed by the animation, if it actually DID take effect before the client even showed it taking effect, or if it was simply a coincidence that it showed up at the start of the anim because of some very lucky timing.

 

One thing that I noted when watching it is that the second rakghoul never takes a single step towards the player throughout the entire video. You can tell when he aggros, because he rears up, but he doesn't take a step until after he gets blown into the air by the grenade anim.

 

Unfortunately the timing's so tight that I can't readily tell if he got frozen in place before or after the grenade anim started: he clearly rears up before the grenade anim begins, but the other 'ghouls don't start moving until shortly after the grenade anim has started. He rears up just a tiny bit after the charged burst finishes its cast time, which is also right when the grenade gets activated...so I also can't tell if he got chain aggro from the burst or direct from the grenade. It's almost precisely simultaneous with the burst's first damage tick, so I'm inclined to think probably chain aggro... but I can't be absolutely sure.

 

That's the thing. Too many variables to be 100% sure about precisely what is actually happening, because there's several alternate possibilities that can't be told apart with that vid.

 

As for this smuggler cover trinket thing...I'm not sure what you mean there either.

 

 

 

Without guesswork through observation, you would not be playing SWTOR right now, because almost none of the technologies used to make it, run it, or that it builds upon would've ever been invented. Practically every bit of knowledge you've learned throughout your life ultimately came out of some guy making a guess based on something he saw.

 

Observation, in fact, is the only way to be SURE of most things in this world.

 

Any help we give them in figuring it out speeds up the process of getting it all fixed.

 

Cramming them all together under one, not entirely accurate banner doesn't help with that. It makes it so that when someone says they're having problems, you can't be sure what problem they're having. It may not actually be all of them! It might only really be one or two. It might be something entirely new that hasn't been reported on yet. You don't know, because they said 'it's not responsive'. How does Bioware find out what's wrong from that?

 

It would, in fact, be far better if each individual problem making up your 'greater whole' had its own thread with separate documentation and information about that bug only.

 

Right now, I have no idea which of those videos in the OP is supposed to reference which problem, and it isn't always apparent from watching them.

 

 

 

As I've said many times, you've already cast the ability before you see it on your screen. Yes it's delayed, but that delay so far as I can tell only affects what you see, not what you can do.

 

The fact that it takes so long to show up is irritating, yes, but shouldn't be impairing your ability to PvP, for the most part.

 

The bugged abilities or the screwed up action queue, on the other hand, might.

 

Negative, you have no idea what is actually happening in the Smuggler Video if you believe that the Grenade effect is timed properly and happens when its supposed to (as soon as the cast time for previous ability finishes).

 

Also your ending statement that its simply delayed on your screen a little... is not only wrong but shows that you don't know what you're talking about.

 

 

Lastly, why don't you retreat into your own thread that you've created in regards to this subject? You have pretty much no-one here agreeing with you.... at all...

[thestackshow]

Why are so many people disagreeing with this. EVERYONE has to deal with it.

 

When you click an instant ability, it takes 0.5 AT LEAST for the ability to cast. It DOES NOT cast right away.

 

That needs to be fixed.

[Xavmobile]

Edited cause thick people. Edited January 6, 2012 by Xavmobile

[ltankhsd]

Just lost two one on one matches with a consular in ilum because I could never interrupt his heals due to my interrupt ability always taking a second before activation.

 

It was time for a break after that.

[Tiron_Raptor]

Negative, you have no idea what is actually happening in the Smuggler Video if you believe that the Grenade effect is timed properly and happens when its supposed to (as soon as the cast time for previous ability finishes).

 

How do you know? You cannot tell from the evidence available on screen in that video what's actually happening. There's too many different things all going on at once for you to be able to isolate something like that and be certain that what you think is happening actually is happening. You literally *cannot* tell for certain what is happening, other than the grenade anim being delayed by the charged burst anim. That is the ONE thing that is absolutely clear.

 

You can guess, you can assume, you can speculate, but you cannot be sure, because there's too many other possibilities that fit the observed facts.

 

In short: need more data.

 

Also your ending statement that its simply delayed on your screen a little... is not only wrong but shows that you don't know what you're talking about.

 

Again, you contradict your statement that you understand it's only what happens on the server that matters.

 

By the time you receive a damage notification on your screen, accompanied by the reduction in the enemy's hitpoints, the server has already calculated the damage done, applied it to the enemy's health, and then calculated how much health it has remaining. It has to have done, because it has to send all that to you before your client can render it, and it takes a short period of time to get to you if nothing else.

 

In the case of the grenade anim, the fact that the damage and debuff appears immediately when the ability starts animating leaves only two possibilities:

 

1.) The client just happened to receive the damage/hp/debuff info from the server at that moment and chose to display it immediately.

2.) The client had already received the damage/hp/debuff info prior to starting the animation, and waited to display it until the animation started.

 

In either case, you end up with the state on the server having been updated before the grenade fires. In the former case, only by a relatively small number of milliseconds(But if this is the case, that would mean the server delayed sending the damage for some reason, which may or may not be related to the animations, though I would speculate more likely not. Either way it's serious problem.). In the latter case, by an indeterminable amount of time that could possibly be less than a second after the ability was activated from the quickslot.

 

Lastly, why don't you retreat into your own thread that you've created in regards to this subject? You have pretty much no-one here agreeing with you.... at all...

 

Maybe because you keep driving the ones less stubborn than I am off? And that thread was only about one of the problems anyway.

 

One which you gave me a lot of crap for reporting, I should add.

[Lawconis]

Yall can chill out, this is suppose to be fixed in one of the few updates coming this month.

 

They said they were fixing responsiveness......

 

Project vs. Shock is not a response issue. Its a design mechanic. Project isn't SUPPOSED to do dmg until the rock hits by DESIGN. Both instant cast, but one doesn't register dmg until after it flies .8 seconds.

 

The code is working properly. It is not a response issue. The problem is that the design is flawed in fairness. One mirror gets their dmg instantly, the other waits .8 seconds. Not a server/client/aesthetic lag.

 

Both classes get to send their message, but one is an instant text message, the other goes via a pigeon courier.

 

Now do you see? Not lag, ...design....

[Froth]

I think the first issue is Client/Server Communication tied in with ability wind up. There is a trooper video that has a .8 sec delay due to Animation wind up.

 

Second is the chaining (rotation) of abilities which is imo 100% Animation Coding.

 

 

Yes I realize that the animation and ability effect are separated etc. thats not the argument. The issue is that their Effect recognition server side is sync'd with animation not input...

 

 

Once again, without Bioware input... we don't not for certain... what we DO know is that its a real problem.

 

Most games shoot first then tell the server later, if this game is doing the reverse, it is doomed.

[samdbtto]

pandas>poor combat, sad but true. Canceled sub. Really tried to be optimistic.

[gavicon]

Angry Birds has better combat.

[Tekeda]

pandas>poor combat, sad but true. Canceled sub. Really tried to be optimistic.

Wow you really tried what like a whole 10 days?

[Lctl]

Angry Birds has better combat.

 

 

 

This made me laugh , loudly:)

[Olzmo]

Wow you really tried what like a whole 10 days?

He probably meant that he pressed an ability and waited the avatar to perform it for about 10 days.

[Kataphraktos]

This is a real pain. I was fighting a boss, and needed to interrupt his one ability. His cast time was 1 second, and yet I could never interrupt in time, even though I was spamming the button as soon as he started it.

 

This issue will really affect endgame, along with no combat log but that's for another thread

[Tiron_Raptor]

Most games shoot first then tell the server later, if this game is doing the reverse, it is doomed.

 

They simulate shooting at the same time they request an attack from the server. It's just a visual-only approximation so it LOOKS like it's not having to wait for the server. There's a ton of ways you can verify this: A particularly easy one here...

 

Using one hit kill hitscan weapons (instant hit, no travel time or leading), get on a server where the other people have much lower ping than you. Say, connecting to a british TF2 server that's currently on a sniper map from the US. Sooner or later, you'll encounter an instance where you aim and fire a kill shot at someone, see the shot fire, and then a mere moment later die and discover that your killer was none other than the guy you fired at. Who is doing just fine, thanks for asking.

 

This game is either doing a piss-poor to nonexistent job of hiding the delay, or has another delay somewhere in the system that's preventing the hiding from working correctly.

 

But practically every online game made in the 21st century works this way, because if the client is allowed to handle it, it becomes trivial to find a way to say that every shot you fire is a one hit kill headshot, never mind that you can't even see the guy.

[Xcore]

How do you know? You cannot tell from the evidence available on screen in that video what's actually happening. There's too many different things all going on at once for you to be able to isolate something like that and be certain that what you think is happening actually is happening. You literally *cannot* tell for certain what is happening, other than the grenade anim being delayed by the charged burst anim. That is the ONE thing that is absolutely clear.

 

You can guess, you can assume, you can speculate, but you cannot be sure, because there's too many other possibilities that fit the observed facts.

 

In short: need more data.

 

 

 

Again, you contradict your statement that you understand it's only what happens on the server that matters.

 

By the time you receive a damage notification on your screen, accompanied by the reduction in the enemy's hitpoints, the server has already calculated the damage done, applied it to the enemy's health, and then calculated how much health it has remaining. It has to have done, because it has to send all that to you before your client can render it, and it takes a short period of time to get to you if nothing else.

 

In the case of the grenade anim, the fact that the damage and debuff appears immediately when the ability starts animating leaves only two possibilities:

 

1.) The client just happened to receive the damage/hp/debuff info from the server at that moment and chose to display it immediately.

2.) The client had already received the damage/hp/debuff info prior to starting the animation, and waited to display it until the animation started.

 

In either case, you end up with the state on the server having been updated before the grenade fires. In the former case, only by a relatively small number of milliseconds(But if this is the case, that would mean the server delayed sending the damage for some reason, which may or may not be related to the animations, though I would speculate more likely not. Either way it's serious problem.). In the latter case, by an indeterminable amount of time that could possibly be less than a second after the ability was activated from the quickslot.

 

 

 

Maybe because you keep driving the ones less stubborn than I am off? And that thread was only about one of the problems anyway.

 

One which you gave me a lot of crap for reporting, I should add.

 

There is no contradiction in any of my statements... I don't even disagree with your theory on Client/Server and general Server argument... all I say is that there is also a definite Animation > Player Input Priority as well as other contributing factors to overall feeling of Disconnect from your avatar.

[Darth_Cliche]

While this is far from game breaking for me, it is probably my biggest issue at the moment. (I am loving the game)

 

Thinking back on it, character responsiveness really was a subconscious aspect that greatly separated wow from the other mmos I played (mainly LOTRO and Warhammer). I especially noticed the lag in LOTRO. Hopefully they will fix this relatively soon.

[Forsbacka]

This is single most annoying thing in this game and it prevents any serious Pve or PvP happening till its fixed. Since its not clear can it even be fixed i canceled and gonna keep close watch on the issue and prolly come back if it gets fixed. No use to play for me unless you cant do anything serious when u hit 50. Edited January 6, 2012 by Forsbacka

[Tiron_Raptor]

There is no contradiction in any of my statements... I don't even disagree with your theory on Client/Server and general Server argument... all I say is that there is also a definite Animation > Player Input Priority as well as other contributing factors to overall feeling of Disconnect from your avatar.

 

Based on the UI feedback from the quickslots and resource bar, it's not so much that the animations are overriding the input as that the animations are happening a considerable amount of time after the input. The input itself actually appears to largely be just as snappy and precise as you'd expect, it just takes a bit before the more obvious results of it are thrown up there.

 

They DO however definitely prioritize making it look good over having the animations respond instantly to new input: They prefer having them play properly to having them constantly clipped, cut off, and otherwise interrupted or badly meshed like they were in WoW. I can't tell you how many times I cast fire blast, saw the blast hit the target instantly, had my hands glow instantly, and had my character jump into the 'I cast a spell!' stance suddenly and abruptly...something like a quarter to half of a second after the other effects started. Looked bloody aweful.

 

I don't think based on what I've observed thus far however that the server is delaying anything based on the animations: for starters the client would have to send the server a message at the least every time it finished an anim, which would exponentially increase the amount of bandwidth used to no good purpose.

 

Far easier to just handle it client side: have the client hang on to the stuff until it can display it smoothly, similar to a technique I've seen used on some flash videos (which also caused people to think it was unresponsive, because it didn't do anything the instant they clicked a button). In which case you'd have to do one of two things as well:

 

1.) Set it up with a timeout, so that if it gets held back too long it overrides the holdback and plays anyway (supported by the anims going to crap in the IA vid, and possibly by the immediate damage on the grenade vid)

 

2.) Have the client delay sending the next attack to the server if it's tied up already, meaning it pretty well needs a queue as well to store what it's delaying.

 

The second option would be a MUCH more efficient way of having the anims delay input, because you don't need to send any extra packets to the server: you just hold them back instead. If I were forced to implement something like this, I'd probably set it up so that it only delayed the send if the client was already holding a result while waiting for an anim to start.

 

The 'find a no-cooldown instant with an animation longer than the GCD and spam it' test would be especially useful for determining which is the case:

 

If it's #1, the anims and the damage notifications will get more and more desynched the more you use it, unless the anims just start clipping at some point, and no activations will ever be skipped: the number of damage ticks dealt would be at least 1 less than the number of times you've activated the ability(unless somehow there's enough lag that two are in transit while one is playing, which'd have to be well over 1 second latency. The key here would be that the difference would remain constant). And when you stopped using the ability, there would be no more than 1 further attack made: the most recent one you activated.

 

If it's #2, the animations should continue to play smoothly, and more or less synced with the damage, no matter how long you keep going. If you watch carefully you'll start to see an increasing mismatch between the number of times you've activated it and the number of times it's done damage. (The 'increasing' part is the key: It'd get worse and worse as you kept going.) When you stopped, one of two things would happen: it plays additional attacks equal to the size of the mismatch (everything was queued), or it plays additional attacks equal to the size of the queue, leaving a certain number of activations that were never manifested (meaning it discarded some: this is the worst possible thing it could be).

 

Additionally, I *believe* that the client is waiting for an acknowledgement from the server before it pulls the resources out. I obviously can't be certain, but the IA video in particular leads me to believe the client doesn't simulate resource pulls (if they're using TCP, the server has to acknowledge receipt of the attack request packet anyway, so it may as well indicate the accepted/rejected status of the attack in the ACK if it can manage to determine it quickly enough). If this is the case, with this same test any holdback or queuing of inputs would show up very fast in the form of increasingly delayed resource pulls.

 

Edit:

There is a trooper video that has a .8 sec delay due to Animation wind up.

 

I don't suppose you could point at me that one? I've got a 42 trooper, and I'd just love to play around with whatever's doing that a bit(if I haven't already)

Edited January 6, 2012 by Tiron_Raptor

[Zeetofox]

Tiron, you sir need to start making TLDR versions...or stop making huge walls of text that only 2 people care enough to read.

[Tiron_Raptor]

Tiron, you sir need to start making TLDR versions...or stop making huge walls of text that only 2 people care enough to read.

 

I do the TLDR versions in response to specific posts.

 

The long ones are largely in-depth theoretical discussions that most people probably aren't even interested in to begin with, frankly...

[Xcore]

Edit:

 

I don't suppose you could point at me that one? I've got a 42 trooper, and I'd just love to play around with whatever's doing that a bit(if I haven't already)

 

How can you post in a thread of which you haven't even read the OP? or seen any of the discussions before joining?

 

 

P.S.: Not going to lie, I stopped reading your actual posts... its very much repetition and I don't have the time...

[Noxxia]

Sure I can accept that. However, in an unresponsive environment like this one cannot create tightly tuned encounters. Ultimately, once the story gets old, you're screwed.

 

Edit: Posted on phone with errors

 

I won't disagree there. End game is my biggest concern for the game.

[Tiron_Raptor]

How can you post in a thread of which you haven't even read the OP? or seen any of the discussions before joining?

 

 

P.S.: Not going to lie, I stopped reading your actual posts... its very much repetition and I don't have the time...

 

Because the OP's really, really long and in places rather hard to follow. Especially when it gets into the videos (with little indication of what they are, or are supposed to show), and the quotes from specific people(which are frankly uninteresting in concept, regardless of content).

 

As far as the videos go, I don't really like watching them in the first place, especially the ones where the guy talks for five minutes before he gets to whatever he's trying to demonstrate. If I can't see something fairly obvious fairly quickly, even after skipping around in the video a bit, I skip to the next one or just stop watching them entirely.

 

It's very much an amplified version of TLDR: If nobody but people who'd read the entire thing posted, this wouldn't be on its fifth thread, it'd've died out days ago.

 

P.S. I wouldn't keep repeating myself if it didn't seem like something wasn't getting through. Think I'm wrong about something? Give me something concrete, and I *will* change my tune.

Edited January 6, 2012 by Tiron_Raptor