In case anyone is wondering why AoE Caps are being removed..Here is the video

david271749

Thudunblundur wrote: »

Question from a computing ignoramus: If one of the main reasons for lag is the number of calculations some bit of electronic machinery has to do, won't the removal of AoE caps massively increase the number of calculation required and so actually increase the lag, especially in breaches and on flags?

I'm sort of assuming this can't be the case, because so many computer savvy people can't have missed it can they? Anyway, I'm curious.

That's what I was thinking. Zos has already said they're going to make aoe damage scale on number of targets hit. Seems like a lot more calculations to me.

Rune_Relic

david271749 wrote: »

Thudunblundur wrote: »

Question from a computing ignoramus: If one of the main reasons for lag is the number of calculations some bit of electronic machinery has to do, won't the removal of AoE caps massively increase the number of calculation required and so actually increase the lag, especially in breaches and on flags?

I'm sort of assuming this can't be the case, because so many computer savvy people can't have missed it can they? Anyway, I'm curious.

That's what I was thinking. Zos has already said they're going to make aoe damage scale on number of targets hit. Seems like a lot more calculations to me.

An agree from me too.
I currently do 6x calcs for each combat aoe.
Now I am going to change that to <insert number of preference here>

Take a zergball of 20.
My aoe only hits x6 (I know some vary) at present so 6 calcs.
Now the caps gone I can hit all 20 people.
So now I have 20x cals to do......per person.
So if there is 20 people hitting the zergball,
where before I only had 20x6 calculations....I now have 20x20 calculations.

Am I really being stupid because that's the only way I can see it going down.
Even worse lag.

I genuinely only see one way to lower this lag ...and that's cutting out the total abuse of aoe in the game. Which means you have to shift players to a more in your face 1 on 1 combat.

[other than make the servers much more powerful and lets face it, that's not going to happen as you are still left with al the extra traffic/bandwidth]

There is also the option of tying range to area....so the greater the range the lower the area (people hit). Not sure that helps so much with PBaoe

Nijjion

What about the calculations with the caps... which 6 targets it has to hit. There's just as much calculating which targets to hit and not to hit than no caps at all.

eventide03b14a_ESO

Wouldn't a simple solution to spamming AoE's simply be to give it the Bolt Escape treatment? If AoE's cost more and hindered your magicka/stamina regeneration after casting wouldn't people use them more judiciously? Yes I am well aware that people still can and do spam BE, but when they do they are moving away from their target. If the same restrictions were in place with AoE's then presumably they would be sitting ducks after getting only 2 or 3 off.

Tankqull

eventide03b14a_ESO wrote: »

Wouldn't a simple solution to spamming AoE's simply be to give it the Bolt Escape treatment? If AoE's cost more and hindered your magicka/stamina regeneration after casting wouldn't people use them more judiciously? Yes I am well aware that people still can and do spam BE, but when they do they are moving away from their target. If the same restrictions were in place with AoE's then presumably they would be sitting ducks after getting only 2 or 3 off.

you would just stack more people to compensate for it.
the problem is not the ability to spam AOEs but to become nearly imune to them by stacking.

Rune_Relic

Nijjion wrote: »

What about the calculations with the caps... which 6 targets it has to hit. There's just as much calculating which targets to hit and not to hit than no caps at all.

Why you you waste cycles on calculations you don't need to do ?
That's just bad coding.

Rune_Relic

eventide03b14a_ESO wrote: »

Wouldn't a simple solution to spamming AoE's simply be to give it the Bolt Escape treatment? If AoE's cost more and hindered your magicka/stamina regeneration after casting wouldn't people use them more judiciously? Yes I am well aware that people still can and do spam BE, but when they do they are moving away from their target. If the same restrictions were in place with AoE's then presumably they would be sitting ducks after getting only 2 or 3 off.

Increase cost = reduced use over time.
So yes...don't see any reason it wont lower aoe use and help
But what of the magicka builds with endless regen ?

Thrymbauld

Honestly, the most simple solution to spamming AOE's really is removing the cap, long before looking at any actual "fix" to the abilities themselves.

The current "best" survival tactic for an AE is to be IN it, with fifty of your best friends. So fifty people, all spamming abilities, all trying to survive, and all trying to move, in the same space the size of an office cubicle. As if that isn't enough, out of that clump of fifty the game has to figure out who is gonna get hit with the AE and who isn't---and a cursory examination suggests that it isn't an entirely random choice amongst the people in that area. Some can go without being hit through the whole salvo, others get blasted to death.

Remove the cap and, yes, AE just got a whole lot badder, because instead of wiping out 1% of your little army, it's capable of wiping out the whole thing if you actually choose to stand in it. Enough so, in fact, that you intensely DO NOT want to be in an area the size of a cubicle with fifty of your best friends. This suddenly means that all those localized calculations are spread out, the timing of them is spread out, and the targets are spread out. Fights become more granular and "manageable", at least on a server and individual player level.

What DOES become more difficult is a keep take. Odds are good that a single breach isn't going to be the norm anymore because a single breach can simply be coated in AE's and pinned down. In the cases of an enormous defense force, it's conceivable that half the wall will have to come down before actual entry can be made to happen, rather than pounding away at a singular breach until the blob "blobs up" enough to soak the AE into nonexistence. Sounds like fun, to be honest.

MorHawk

Thrymbauld wrote: »

What DOES become more difficult is a keep take. Odds are good that a single breach isn't going to be the norm anymore because a single breach can simply be coated in AE's and pinned down. In the cases of an enormous defense force, it's conceivable that half the wall will have to come down before actual entry can be made to happen, rather than pounding away at a singular breach until the blob "blobs up" enough to soak the AE into nonexistence. Sounds like fun, to be honest.

Multiple forks of attack, decoys, distractions...you're right, that sounds awesome.

frosth.darkomenb16_ESO

Rune_Relic wrote: »

Take a zergball of 20.
My aoe only hits x6 (I know some vary) at present so 6 calcs.
Now the caps gone I can hit all 20 people.
So now I have 20x cals to do......per person.
So if there is 20 people hitting the zergball,
where before I only had 20x6 calculations....I now have 20x20 calculations.

Am I really being stupid because that's the only way I can see it going down.
Even worse lag.

You're not being stupid, you just don't take everything into account.
Perhaps you've never programmed before?

Now an aoe can only affect 6 targets, but it has 20 targets it knows about and has to decide from. Also, due to the increased survivability, you have x amount of times more aoes being casted.
For example, a group of 24 stacked and afk would need at best 40 attacks instead of 10 before getting killed. But it should be more if the random repartition isn't perfect.
If they are active, with the use of smart healing, they can last possibly forever.
This increases the amount of spam necessary in the game.

Not to mention that smart healing, if they want to have accurate results, requires to lock the hp of the targets until it has decided which players need heals the most. This is a possible explanation to the "no longer any damage" bug, probably due to concurency.
Even if they don't care about acurate results, sorting, depending on the size of a list, can be a bit complex and expensive. Definitely a lot more than just applying the effect on all targets in the list.

But here's the thing ,without aoe caps, there won't be an equivalent amount of targets. People will spread out so the max amount of targets to hit and/or sort will be much lower. If we take launch times, or noob forces fighting each other or just trying to calculate player density, aoes rarely have more than 4 targets at a time in their radius.

And without the cap, there won't be the same survivability. In the case that a groop is stacked, instead of a potential infinite spam, only 10 attacks would be enough to criple that group, no matter its size.
And we know by looking at the mana costs and the heal per second of healing spells that tanking isn't possible under focus fire of an equivalent group.

I hope this helps understanding the technical issue at hand.

Samadhi

Rune_Relic wrote: »

Nijjion wrote: »

What about the calculations with the caps... which 6 targets it has to hit. There's just as much calculating which targets to hit and not to hit than no caps at all.

Why you you waste cycles on calculations you don't need to do ?
That's just bad coding.

Agreed, AoE caps are bad coding.
Be better to remove AoE caps and eliminate the excess calculations all together.

At least ZOS is taking steps forward on the issue rather than standing still though.

reften

Domander wrote: »

unfortunately without aoe caps that fight would be over really really fast, I don't know what the solution is... but super fast aoe smackdown fights don't sound fun either.

EXACTLY!!!!!

Be careful what you wish for people...

frosth.darkomenb16_ESO

oren74 wrote: »

Domander wrote: »

unfortunately without aoe caps that fight would be over really really fast, I don't know what the solution is... but super fast aoe smackdown fights don't sound fun either.

EXACTLY!!!!!

Be careful what you wish for people...

Nope, wrong, not "exactly".

Have you been in fights where large force didn't know about the target caps?
I'll assume you haven't.

Turns out they last just as long, perhaps even longer.
It's definitely longer than when only one side knows about the cap and rolls over the other one in seconds.

It's just that the fights are different, and occur a lot more on the outside of the keeps. The last push is rarely as quick as with stacking since you don't ignore the defenders and jump on the flag. There is a lot more preparations.
When the inner keep goes down, you need to slowly kill off the defenders and cause attrition in order to capture the keep.
You get the reward only when you have actually won the battle.

Will group stacking die off quickly? Yes, but fights will definitely last longer.

Grim13

"Mega" server... "mega"

- I do not think that word means what zos thinks it means...

smacx250

From a computational standpoint, the actual "target cap" calculation that are being discussed are literally "nothing" for any modern cpu in the numbers of players in a given battle we are talking about (< 1000). If there is any affect of these changes on lag, it won't have anything to do with the computational complexity of performing the "caps" calculations.

Server CPUs are turning more than 300 GFLOPS (300 Billion Floating point OPs Per Second). If you had a 1000 players, there would be 5 million floating point ops available for each player during each frame tic (assuming 60 fps) from a single CPU. I am NOT saying all this madness isn't responsible for lag - but it certainly isn't the computational complexity of determining the caps that is at issue. Now back to our suspension of reality...

frosth.darkomenb16_ESO

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".

There is an observable drop in performances with different player behavior.
Meaning that for equivalent amount of players and activity, one case timesout the servers, the other doesn't.
And that change in behavior, stacking, is caused by target caps.
That is the reality.

Now as to why this causes lag, there could be multiple bottlenecks.
First, having to update so often so many players could cause a bandwidth bottleneck.
Which is very likely why recent f2p fpses devolved into 4v4 or 8v8 at most.

Stacking and the target caps ensure more survivability for groups and the random repartition make characters not die until the group's "effective hp tank" breaks. So you have 24 people requiring in the the best case scenario 4 times more attacks than necessary. But the odds of that hapening are extremely low, so it is always way more than that.

Then there is the second culprit: smart healing.
It may be affecting only 6 targets, but it does so by sorting out all targets available in its area.
Instead of affecting X targets, it has to sort X targets, and due to player behaviors is multiple times per seconds per player.
Sorting is always multiple times more costly than just iterating once in the list. (usually between N iterations up to N cube, but it depends on the algorithm)
I assume Zos engineers are smart, so their infrastructures are probably good enough for the amount of players the campaigns are caped at +20-40%.
But those kind of calculations due to anormal player behavior blows through that "just in case" budget.

And finaly, still on the smart healing front, if you want accurate results in this dynamic environment, you have to lock the state of hitpoints until the sort is done and targets selected.
Which means that the next heals and damages effects including one of these targets would need the previous one to be resolved.
This causes latency unrelated to computational power but due to concurrency.

I suspect that the state we see in those videos is due to this. After a while, there are so many characters being locked that it ends up in a deadlock.
Players keep trying to attack, and that causes the server to crash due to memory getting thin.

Sure they could just fix the deadlock issue and upgrade server capacity, but it would be an ongoing waste of money when they could simply change the game design to remove the source of the bug without having to fix it and improve both the gameplay and the performances in one go.

Cysapper

Tankqull wrote: »

Cysapper wrote: »

Here is why they added the AOE cap welcome the return of the infinity tank!

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

just watched this video - duringt the entire 13min he was not once effecting more than 4 players with his aoe´s so what exactly is your point again? (he once fought 5 npc guards)

couldn't find the vid where he solo took a scroll

Nijjion

Rune_Relic wrote: »

Why you you waste cycles on calculations you don't need to do ?
That's just bad coding.

Well wouldn't put it past the coders over at Zenimax, I've lost count how many times something has broken in the game and it was completely irrelevant to anything they changed in that patch.

Not sure how they do it but they do.

smacx250

frosth.darkomenb16_ESO wrote: »

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".
<snip>

I don't believe anything I said was "haughty" - I'm sorry if it came across that way. There have been many posts where people have suggested the complexity of the target cap and/or damage calculations themselves are a cause of lag, and I don't believe that to be the case. I do admit that the "madness" resulting from AoE caps may very well be a cause of lag:

I am NOT saying all this madness isn't responsible for lag - but it certainly isn't the computational complexity of determining the caps that is at issue.

Are you agreeing or disagreeing with me? Or was your reply to my post an opportunity to rehash what you posted earlier, and really had nothing to do with what I was saying?

reften

really this just is a non-issue...I run Cyrodiil every single night and it hasn't been a problem. Don't fix what isn't broken.

frosth.darkomenb16_ESO

smacx250 wrote: »

frosth.darkomenb16_ESO wrote: »

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".
<snip>

I don't believe anything I said was "haughty" - I'm sorry if it came across that way. There have been many posts where people have suggested the complexity of the target cap and/or damage calculations themselves are a cause of lag, and I don't believe that to be the case. I do admit that the "madness" resulting from AoE caps may very well be a cause of lag:

I am NOT saying all this madness isn't responsible for lag - but it certainly isn't the computational complexity of determining the caps that is at issue.

Are you agreeing or disagreeing with me? Or was your reply to my post an opportunity to rehash what you posted earlier, and really had nothing to do with what I was saying?

My post was me disagreeing directly with what you were saying.
It wasn't a rehash, I actually went in more details than I ever did on the technical aspect of the issue. (for me, the lag is secundary to the bad gameplay it causes)

While you aren't wrong that calculating the caps isn't heavy in a vacuum, it is an order of complexity higher than not having them. (n to n x n)
See the part on the sorting necessary for smart healing.

It also needs to be a single process in order to get accurate results.
If there were no caps, you could treat targets as they are getting discovered rather than wait for a complete list to be formed.
And each of those individual targets would be locked individually and treated faster than if the entire list had to be locked, sorted and treated before getting released.
See the part on the deadlock.

Those two are reasons why the cap themselves are a source of lag.

Of course, perhaps the issue here is smart healing rather than target caps. But the game's only sustainably spammable heal is an aoe that is capped like damage aoes are, and wouldn't be smart if it wasn't for the target caps.

In any case, the cap impacts player behavior, which is also a matter of engineering in my opinion. It is the context in which the software has to be developped and any solution has to take that into account.

Rune_Relic

frosth.darkomenb16_ESO wrote: »

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".

There is an observable drop in performances with different player behavior.
Meaning that for equivalent amount of players and activity, one case timesout the servers, the other doesn't.
And that change in behavior, stacking, is caused by target caps.
That is the reality.

Now as to why this causes lag, there could be multiple bottlenecks.
First, having to update so often so many players could cause a bandwidth bottleneck.
Which is very likely why recent f2p fpses devolved into 4v4 or 8v8 at most.

Stacking and the target caps ensure more survivability for groups and the random repartition make characters not die until the group's "effective hp tank" breaks. So you have 24 people requiring in the the best case scenario 4 times more attacks than necessary. But the odds of that hapening are extremely low, so it is always way more than that.

Then there is the second culprit: smart healing.
It may be affecting only 6 targets, but it does so by sorting out all targets available in its area.
Instead of affecting X targets, it has to sort X targets, and due to player behaviors is multiple times per seconds per player.
Sorting is always multiple times more costly than just iterating once in the list. (usually between N iterations up to N cube, but it depends on the algorithm)
I assume Zos engineers are smart, so their infrastructures are probably good enough for the amount of players the campaigns are caped at +20-40%.
But those kind of calculations due to anormal player behavior blows through that "just in case" budget.

And finaly, still on the smart healing front, if you want accurate results in this dynamic environment, you have to lock the state of hitpoints until the sort is done and targets selected.
Which means that the next heals and damages effects including one of these targets would need the previous one to be resolved.
This causes latency unrelated to computational power but due to concurrency.

I suspect that the state we see in those videos is due to this. After a while, there are so many characters being locked that it ends up in a deadlock.
Players keep trying to attack, and that causes the server to crash due to memory getting thin.

Sure they could just fix the deadlock issue and upgrade server capacity, but it would be an ongoing waste of money when they could simply change the game design to remove the source of the bug without having to fix it and improve both the gameplay and the performances in one go.

I take it you mean dump smart heal ?

frosth.darkomenb16_ESO

Rune_Relic wrote: »

frosth.darkomenb16_ESO wrote: »

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".

There is an observable drop in performances with different player behavior.
Meaning that for equivalent amount of players and activity, one case timesout the servers, the other doesn't.
And that change in behavior, stacking, is caused by target caps.
That is the reality.

Now as to why this causes lag, there could be multiple bottlenecks.
First, having to update so often so many players could cause a bandwidth bottleneck.
Which is very likely why recent f2p fpses devolved into 4v4 or 8v8 at most.

Stacking and the target caps ensure more survivability for groups and the random repartition make characters not die until the group's "effective hp tank" breaks. So you have 24 people requiring in the the best case scenario 4 times more attacks than necessary. But the odds of that hapening are extremely low, so it is always way more than that.

Then there is the second culprit: smart healing.
It may be affecting only 6 targets, but it does so by sorting out all targets available in its area.
Instead of affecting X targets, it has to sort X targets, and due to player behaviors is multiple times per seconds per player.
Sorting is always multiple times more costly than just iterating once in the list. (usually between N iterations up to N cube, but it depends on the algorithm)
I assume Zos engineers are smart, so their infrastructures are probably good enough for the amount of players the campaigns are caped at +20-40%.
But those kind of calculations due to anormal player behavior blows through that "just in case" budget.

And finaly, still on the smart healing front, if you want accurate results in this dynamic environment, you have to lock the state of hitpoints until the sort is done and targets selected.
Which means that the next heals and damages effects including one of these targets would need the previous one to be resolved.
This causes latency unrelated to computational power but due to concurrency.

I suspect that the state we see in those videos is due to this. After a while, there are so many characters being locked that it ends up in a deadlock.
Players keep trying to attack, and that causes the server to crash due to memory getting thin.

Sure they could just fix the deadlock issue and upgrade server capacity, but it would be an ongoing waste of money when they could simply change the game design to remove the source of the bug without having to fix it and improve both the gameplay and the performances in one go.

I take it you mean dump smart heal ?

hum, no.
I mean remove aoe target caps on everything, especially on healing aoes.
it will change player behavior in a way that reduces server load and improve gameplay.

Smart healing is fine and a great mechanic for templars 3 target spells or for stuff like healing ward.

smacx250

frosth.darkomenb16_ESO wrote: »

smacx250 wrote: »

frosth.darkomenb16_ESO wrote: »

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".
<snip>

I don't believe anything I said was "haughty" - I'm sorry if it came across that way. There have been many posts where people have suggested the complexity of the target cap and/or damage calculations themselves are a cause of lag, and I don't believe that to be the case. I do admit that the "madness" resulting from AoE caps may very well be a cause of lag:

I am NOT saying all this madness isn't responsible for lag - but it certainly isn't the computational complexity of determining the caps that is at issue.

Are you agreeing or disagreeing with me? Or was your reply to my post an opportunity to rehash what you posted earlier, and really had nothing to do with what I was saying?

My post was me disagreeing directly with what you were saying.
It wasn't a rehash, I actually went in more details than I ever did on the technical aspect of the issue. (for me, the lag is secundary to the bad gameplay it causes)

While you aren't wrong that calculating the caps isn't heavy in a vacuum, it is an order of complexity higher than not having them. (n to n x n)
See the part on the sorting necessary for smart healing.

It also needs to be a single process in order to get accurate results.
If there were no caps, you could treat targets as they are getting discovered rather than wait for a complete list to be formed.
And each of those individual targets would be locked individually and treated faster than if the entire list had to be locked, sorted and treated before getting released.
See the part on the deadlock.

Those two are reasons why the cap themselves are a source of lag.

Of course, perhaps the issue here is smart healing rather than target caps. But the game's only sustainably spammable heal is an aoe that is capped like damage aoes are, and wouldn't be smart if it wasn't for the target caps.

In any case, the cap impacts player behavior, which is also a matter of engineering in my opinion. It is the context in which the software has to be developped and any solution has to take that into account.

Thank you for clarifying that.

Note that if what you surmise is true, we should expect lag to increase when ZOS implements their proposed AoE target cap "removal", as for large numbers of targets it will actually increase the calculations that are required (count all targets as they are found, calculate damage modifier, apply modified damage to all the targets) over what the AoE target cap does now (RNG weight each target as it is found, keep pointers to the six top weight targets, and apply damage to only those six targets).

Also note that there is no need for sorting to process smart healing - all one needs to do is keep track of the "X" lowest health players as the targets are traversed, which is much less compute intensive than a true sort.

Sleep

I think that's the lag, not the problem of aoe cap. Though I think removing the aoe cap could be good.

frosth.darkomenb16_ESO

smacx250 wrote: »

frosth.darkomenb16_ESO wrote: »

smacx250 wrote: »

frosth.darkomenb16_ESO wrote: »

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".
<snip>

I don't believe anything I said was "haughty" - I'm sorry if it came across that way. There have been many posts where people have suggested the complexity of the target cap and/or damage calculations themselves are a cause of lag, and I don't believe that to be the case. I do admit that the "madness" resulting from AoE caps may very well be a cause of lag:

I am NOT saying all this madness isn't responsible for lag - but it certainly isn't the computational complexity of determining the caps that is at issue.

Are you agreeing or disagreeing with me? Or was your reply to my post an opportunity to rehash what you posted earlier, and really had nothing to do with what I was saying?

My post was me disagreeing directly with what you were saying.
It wasn't a rehash, I actually went in more details than I ever did on the technical aspect of the issue. (for me, the lag is secundary to the bad gameplay it causes)

While you aren't wrong that calculating the caps isn't heavy in a vacuum, it is an order of complexity higher than not having them. (n to n x n)
See the part on the sorting necessary for smart healing.

It also needs to be a single process in order to get accurate results.
If there were no caps, you could treat targets as they are getting discovered rather than wait for a complete list to be formed.
And each of those individual targets would be locked individually and treated faster than if the entire list had to be locked, sorted and treated before getting released.
See the part on the deadlock.

Those two are reasons why the cap themselves are a source of lag.

Of course, perhaps the issue here is smart healing rather than target caps. But the game's only sustainably spammable heal is an aoe that is capped like damage aoes are, and wouldn't be smart if it wasn't for the target caps.

In any case, the cap impacts player behavior, which is also a matter of engineering in my opinion. It is the context in which the software has to be developped and any solution has to take that into account.

Thank you for clarifying that.

Note that if what you surmise is true, we should expect lag to increase when ZOS implements their proposed AoE target cap "removal", as for large numbers of targets it will actually increase the calculations that are required (count all targets as they are found, calculate damage modifier, apply modified damage to all the targets) over what the AoE target cap does now (RNG weight each target as it is found, keep pointers to the six top weight targets, and apply damage to only those six targets).

Also note that there is no need for sorting to process smart healing - all one needs to do is keep track of the "X" lowest health players as the targets are traversed, which is much less compute intensive than a true sort.

Agreed on the first point. That's why I'm against that change.

Their considered solution is a small step in the right direction, but it doesn't change much. It isn't really a removal of the caps.
Gameplay wise, it just changes a hard cap for a soft cap and there may still be an incentive to stack depending on how steep the fall off is.
And it doesn't really improve anything on the computation side.

On the sorting ,you're correct. There is no need to sort the entire list. Your proposed implementation would only have a small overhead for assignations, but nothing drastic.
It's still slightly higher than no caps, but it isn't a valid argument anymore.
Thanks for pointing that out.

There is still noticeable lag increased by the usage of this tactic.
Do you think it can be attributed a bit to concurency issues (since it ends up in a deadlock) or to player behavior only?

While you do have a valid point about individual calculations being lightweight, the "madness" this mechanic causes is a source of lag the servers can't handle.
It is interesting to discuss why it happens but, as I said bebore, the gameplay is the primary issue.

maxilaub17_ESO

xsorusb14_ESO wrote: »

https://www.youtube.com/watch?v=DBxXjYjgSIc

*grin*

WRONG!!!! THAT'S NOT AN AOE CAP ISSUE, server side you are not where your client is showing and the players on your screen are out of sync with your client too. What a bunch of BS.

The only thing I feel about AOE caps is these zerg ball AOE spams have to go period they ruin real skill based PvP.

Xsorus

maxilaub17_ESO wrote: »

xsorusb14_ESO wrote: »

https://www.youtube.com/watch?v=DBxXjYjgSIc

*grin*

WRONG!!!! THAT'S NOT AN AOE CAP ISSUE, server side you are not where your client is showing and the players on your screen are out of sync with your client too. What a bunch of BS.

The only thing I feel about AOE caps is these zerg ball AOE spams have to go period they ruin real skill based PvP.

you realize i'm standing in the same spot for a good portion of the video right?

CoolsHisHands

maxilaub17_ESO wrote: »

WRONG!!!! THAT'S NOT AN AOE CAP ISSUE, server side you are not where your client is showing and the players on your screen are out of sync with your client too. What a bunch of BS.

The video is 12 minutes long of him just wandering around 50 baddies spamming impulse... Are you saying he was 12 minutes out of sync? :headscratch:

smacx250

frosth.darkomenb16_ESO wrote: »

smacx250 wrote: »

frosth.darkomenb16_ESO wrote: »

smacx250 wrote: »

frosth.darkomenb16_ESO wrote: »

@smacx250‌
If you had paid attention to the thread and discussions, perhaps you wouldn't be so haughty and would know what we mean by "target caps cause lag".
<snip>

I don't believe anything I said was "haughty" - I'm sorry if it came across that way. There have been many posts where people have suggested the complexity of the target cap and/or damage calculations themselves are a cause of lag, and I don't believe that to be the case. I do admit that the "madness" resulting from AoE caps may very well be a cause of lag:

I am NOT saying all this madness isn't responsible for lag - but it certainly isn't the computational complexity of determining the caps that is at issue.

Are you agreeing or disagreeing with me? Or was your reply to my post an opportunity to rehash what you posted earlier, and really had nothing to do with what I was saying?

My post was me disagreeing directly with what you were saying.
It wasn't a rehash, I actually went in more details than I ever did on the technical aspect of the issue. (for me, the lag is secundary to the bad gameplay it causes)

While you aren't wrong that calculating the caps isn't heavy in a vacuum, it is an order of complexity higher than not having them. (n to n x n)
See the part on the sorting necessary for smart healing.

It also needs to be a single process in order to get accurate results.
If there were no caps, you could treat targets as they are getting discovered rather than wait for a complete list to be formed.
And each of those individual targets would be locked individually and treated faster than if the entire list had to be locked, sorted and treated before getting released.
See the part on the deadlock.

Those two are reasons why the cap themselves are a source of lag.

Of course, perhaps the issue here is smart healing rather than target caps. But the game's only sustainably spammable heal is an aoe that is capped like damage aoes are, and wouldn't be smart if it wasn't for the target caps.

In any case, the cap impacts player behavior, which is also a matter of engineering in my opinion. It is the context in which the software has to be developped and any solution has to take that into account.

Thank you for clarifying that.

Note that if what you surmise is true, we should expect lag to increase when ZOS implements their proposed AoE target cap "removal", as for large numbers of targets it will actually increase the calculations that are required (count all targets as they are found, calculate damage modifier, apply modified damage to all the targets) over what the AoE target cap does now (RNG weight each target as it is found, keep pointers to the six top weight targets, and apply damage to only those six targets).

Also note that there is no need for sorting to process smart healing - all one needs to do is keep track of the "X" lowest health players as the targets are traversed, which is much less compute intensive than a true sort.

Agreed on the first point. That's why I'm against that change.

Their considered solution is a small step in the right direction, but it doesn't change much. It isn't really a removal of the caps.
Gameplay wise, it just changes a hard cap for a soft cap and there may still be an incentive to stack depending on how steep the fall off is.
And it doesn't really improve anything on the computation side.

On the sorting ,you're correct. There is no need to sort the entire list. Your proposed implementation would only have a small overhead for assignations, but nothing drastic.
It's still slightly higher than no caps, but it isn't a valid argument anymore.
Thanks for pointing that out.

There is still noticeable lag increased by the usage of this tactic.
Do you think it can be attributed a bit to concurency issues (since it ends up in a deadlock) or to player behavior only?

While you do have a valid point about individual calculations being lightweight, the "madness" this mechanic causes is a source of lag the servers can't handle.
It is interesting to discuss why it happens but, as I said bebore, the gameplay is the primary issue.

Your deadlock theory is an interesting one - though I wonder if it is more rightly a livelock issue. If there are multiple threads going after a common set of lockable resources, deadlock avoidance mechanisms in the code (e.g., not holding one lock while waiting for another) can actually lead to livelock. Livelock can manifest itself much in the way the video shows - long periods of time where seemingly no progress (damage) is made, but once in a while some progress (damage) occurs, and then things stop again. Basically, a number of threads are spinning around each other trying to get access to common resources, but only rarely (or never) can any one thread get all the resources it needs, as some resources are almost always held by other threads. It also tends to be harder to debug than deadlock (deadlock is usually a hard fail). But without any clue of how the server implements any of this stuff - it's pretty wild speculation!