Guild Wars 2

The invisible holy trinity is very much present in this game, albeit in the form of spec discrimination.

Every combination of classes/specs is viable!*

*: Except for more than one condition spec of a particular type.

It’s so disheartening as a condition class to see those 25 stacks up and begin swinging, because you realize you aren’t really contributing past that very small part of your damage that wasn’t entirely negated by developer laziness.

Seriously, increase the total number of condition stacks on world bosses, at the very least to 50-60. Is it not enough that you have a myriad of condition immune things in dungeons just to make the condition specs feel impotent?

While having played my fair share of holy trinity MMOs where you could only have a certain ratio of stuff, I’ve never seen a raid intended for dozens of people where you couldn’t have more than a couple classes of a certain type.

I can deal with 5 mans turning me down and having to turn down condition specced people myself, who might have the best gear in the game, merely due to the fact that their damage would be negated by these poorly thought out mechanics, but for World Bosses.. please…..have some mercy.

This has been argued since release.

AFAIK it’s possible to increase stacks but the bandwidth issues would cause massive lag.

So which is better? Have everyone suffer because of your condition build? Or just have you suffer because of your condition build? I’d take the former. Just move off a condition build.

Vol.5241:

This has been argued since release.

AFAIK it’s possible to increase stacks but the bandwidth issues would cause massive lag.

So which is better? Have everyone suffer because of your condition build? Or just have you suffer because of your condition build? I’d take the former. Just move off a condition build.

LOL what? Are you serious? You’re telling me that somehow an action that is determined after no less than half a second, that doesn’t have the ability to crit (and thus doesn’t require any additional simulation server side) is somehow more encumbering than anything else with a short cooldown ability that can crit and requires the same number of calculations for everything else?

Vol.5241:

This has been argued since release.

AFAIK it’s possible to increase stacks but the bandwidth issues would cause massive lag.

So which is better? Have everyone suffer because of your condition build? Or just have you suffer because of your condition build? I’d take the former. Just move off a condition build.

If the solution to a problem created by game design is to abandon a choice in build design, then why have the choice in the game at all?

crestpiemangler.7631:

LOL what? Are you serious? You’re telling me that somehow an action that is determined after no less than half a second, that doesn’t have the ability to crit (and thus doesn’t require any additional simulation server side) is somehow more encumbering than anything else with a short cooldown ability that can crit and requires the same number of calculations for everything else?

The thing is that every single stack requires data to be sent to and from the server, and for every thing sent the load increases and increasing the load even more is most likely not advisable.

crestpiemangler.7631:

Vol.5241:

This has been argued since release.

AFAIK it’s possible to increase stacks but the bandwidth issues would cause massive lag.

So which is better? Have everyone suffer because of your condition build? Or just have you suffer because of your condition build? I’d take the former. Just move off a condition build.

LOL what? Are you serious? You’re telling me that somehow an action that is determined after no less than half a second, that doesn’t have the ability to crit (and thus doesn’t require any additional simulation server side) is somehow more encumbering than anything else with a short cooldown ability that can crit and requires the same number of calculations for everything else?

Just cause it seems simple doesnt’ mean it isn’t. I’m not a programmer, and I don’t think you are either, but consider that the servers have to keep in consideration the
a.) type of condition
b.) duration of condition with each stack
c.) The dmg tick of each condition

And then take all the above and multiply it by the number of players applying it on a single boss, or any other group of high-HP mobs?

That’s massive lag.

Something along the lines of increasing the intensity of some conditions but cutting the duration may help address this. This should only apply to PvE however as it would cause issues in PvP balance, but shouldn’t upset anything in PvE.

lordkrall.7241:

crestpiemangler.7631:

LOL what? Are you serious? You’re telling me that somehow an action that is determined after no less than half a second, that doesn’t have the ability to crit (and thus doesn’t require any additional simulation server side) is somehow more encumbering than anything else with a short cooldown ability that can crit and requires the same number of calculations for everything else?

The thing is that every single stack requires data to be sent to and from the server, and for every thing sent the load increases and increasing the load even more is most likely not advisable.

That very same process is used for every attack in the game. I guess people should stop using abilities to decrease server load then.

Vol.5241:

This has been argued since release.

AFAIK it’s possible to increase stacks but the bandwidth issues would cause massive lag.

So which is better? Have everyone suffer because of your condition build? Or just have you suffer because of your condition build? I’d take the former. Just move off a condition build.

It wouldn’t cause lag, they’re tracked server side, if they removed them they would just need to dedicate more bandwidth to tracking, which would mean expanding servers, which would cost money.

They’ve said several times that they are working on it, even that they had a solution, but that was months ago, and they seem to be have been completely avoiding the subject since. I’m hoping that that solution didn’t fail, and ANet isn’t back to the ‘ignore it and hope the players forget about it’ plan.

I think you are mixing up ‘viable’ and ‘optimal’ yet I do agree that the cap should be raised if possible.

IndigoSundown.5419:

Vol.5241:

This has been argued since release.

AFAIK it’s possible to increase stacks but the bandwidth issues would cause massive lag.

So which is better? Have everyone suffer because of your condition build? Or just have you suffer because of your condition build? I’d take the former. Just move off a condition build.

If the solution to a problem created by game design is to abandon a choice in build design, then why have the choice in the game at all?

I guess because even though it causes problems on a massive scale, it’s not a problem worth redesigning the whole game for. You’d have to redesign the necromancer, redesign all the items in game with condition damage and duration.

They dont want to adjust their servers to handle condition stacking.

therefore, condition builds aren’t viable.

A higher cap to stacks will not cause any lag.

Vol.5241:

This has been argued since release.

Just cause it seems simple doesnt’ mean it isn’t. I’m not a programmer, and I don’t think you are either, but consider that the servers have to keep in consideration the
a.) type of condition
b.) duration of condition with each stack
c.) The dmg tick of each condition

And then take all the above and multiply it by the number of players applying it on a single boss, or any other group of high-HP mobs?

That’s massive lag.

Those calculations are done server side and are trivial to make. I don’t think you understand how powerful a modern CPU really is compared to a calculator.

What do you define by a programmer? Somebody who has programmed in an OOP language? I’m pretty sure most people on this forum fall into that category.

crestpiemangler.7631:

That very same process is used for every attack in the game. I guess people should stop using abilities to decrease server load then.

And yet the vast majorities of those attacks don’t happen several times within a second, which conditions does.

lordkrall.7241:

crestpiemangler.7631:

That very same process is used for every attack in the game. I guess people should stop using abilities to decrease server load then.

And yet the vast majorities of those attacks don’t happen several times within a second, which conditions does.

That is done serverside, not client side, since you cease to affect anything after the application.

One solution for making condition builds more valuable would be adding more high-toughness enemies. While all of the damage from all those zerkers would be greatly reduced, conditions would bite right through. We already have a ton of bosses and enemies countering conditions, let’s have some justice!

crestpiemangler.7631:

That is done serverside, not client side, since you cease to affect anything after the application.

Not all of it

The solution is simple indeed. Make enemies able to receive just a finite amount of direct attacks per second (let’s say 2 or 3) so they’ll both work in the same way.
Yeah, i’m being sarcastic. I wonder why they implemented the condition system as is, knowing that it doesn’t really work with groups.
And i still can’t understand why they introduced an additional condition after all.

It doesn’t have to be uncapped. The problem is that a single person can keep 25 stacks of bleed pretty easily if you’re spec’d for that. How about we just double the cap?

It’d be much harder for two or even three people to keep 50 stacks. In a dungeon environment, that’s perfectly acceptable.

If the cap of 25 was player based it would be fine but with that being the total cap between all players it is nothing short of a joke. Perhaps have an individual player cap for condition on bosses but scale it down a bit for each player applying the same condition. Something like if five players apply bleed then reduce the damage by like 5 or 10 for each player so it’s not to OP but still has respectable enough damage to keep condition builds viable. There is a way to make something like this work.

Katai.6240:

It doesn’t have to be uncapped. The problem is that a single person can keep 25 stacks of bleed pretty easily if you’re spec’d for that. How about we just double the cap?

It’d be much harder for two or even three people to keep 50 stacks. In a dungeon environment, that’s perfectly acceptable.

But what about things like burning? With just an off-hand torch on my ranger I can close to, if not fully, maintain burning on an enemy. If I’m using traps and a shortbow as well I can maintain burning and poison on multiple enemies.

This is a larger problem than bleed stacks in my opinion, as a single player can fully maintain burning or poison, which only has 1 stack effecting the opponent.

I’ve actually quit using condition damage focused builds all together, mainly because someone else in the party already has burning and/or poison up 50% or longer during the fight, cutting the effect of any conditions I would apply and potentially making them useless.

Supposedly there’s technical limitations due to having to keep track of each stack on everyone, but reality suggests that 25 stacks was too easy to reach.

I just don’t think this was well planned.

crestpiemangler.7631:

Vol.5241:

This has been argued since release.

Just cause it seems simple doesnt’ mean it isn’t. I’m not a programmer, and I don’t think you are either, but consider that the servers have to keep in consideration the
a.) type of condition
b.) duration of condition with each stack
c.) The dmg tick of each condition

And then take all the above and multiply it by the number of players applying it on a single boss, or any other group of high-HP mobs?

That’s massive lag.

Those calculations are done server side and are trivial to make. I don’t think you understand how powerful a modern CPU really is compared to a calculator.

What do you define by a programmer? Somebody who has programmed in an OOP language? I’m pretty sure most people on this forum fall into that category.

AFAIK (don’t have the sources offhand, just remember reading it) it isn’t the actual calculation of each stack what’s the problem, the problem is the bandwith used.

Each attack generates information sent to the server, which in turn calculates the effects that attack had, and sends the information back to the clients (meaning, everyone in range of the mob being attacked). Problem with conditions is that for every tick you have multiple stacks, each with different stats attached to them (each stack depends on the condition damage of the player that applied it), which need to be sent to the server, the server calculates how much damage each stack applies, and then needs to send that information back to every single client in range of the mob being attacked, and do the same for every type of condition.

AFAIK it’s not the server power that made the condition cap necessary, it’s the bandwith that’s limiting it because of the amount of data that the servers needs to receive and communicate with the clients on each tick of conditions, specially on the last leg (meaning between your ISP and your computer), which is completely out of control of Anet considering that they have to make the game playable across a wide range of connection speeds and latency.

ArchonWing.9480:

Supposedly there’s technical limitations due to having to keep track of each stack on everyone, but reality suggests that 25 stacks was too easy to reach.

I just don’t think this was well planned.

It’s really insulting when I read that this is some kind of technical limitation, when WvW is a technical marvel by itself and a single PvE world boss is like the logarithm of the complexity thereof.

They ought to just be honest and say: “we want more spec diversity.” Ok, that’s fine, but if you’re going to do that in such a fashion, you have to make sure that you’re not excluding a spec entirely by default as the expected number of players rises.

This isn’t such a difficult problem to solve either. Increasing the cap to 50 for world bosses would not fundamentally change the game.

locoman.1974:

AFAIK it’s not the server power that made the condition cap necessary, it’s the bandwith that’s limiting it because of the amount of data that the servers needs to receive and communicate with the clients on each tick of conditions, specially on the last leg (meaning between your ISP and your computer), which is completely out of control of Anet considering that they have to make the game playable across a wide range of connection speeds and latency.

Let’s assume that were true. Then why is it possible to concomitantly apply more than 25 conditions to separate mobs, e.g. through epidemic? It would have to use the same bandwidth, something that they are claiming is impossible for a single mob.

Manuhell.2759:

I wonder why they implemented the condition system as is, knowing that it doesn’t really work with groups.

Imo it was to provide theorycrafters the opportunity to design builds which were capable of generating max stacks of conditions by themselves. Without going to that effort, players are not going to generate that many stacks. Thus, players who make that effort to maximize a condition build get rewarded with better dps — just not in any content where there are more than one of them.

@Vol

Yeah, I agree that this is — once again — a ship that has sailed. That doesn’t mean it shouldn’t be discussed — on the off-chance a solution can be found.

And you’re not going to get people to leave it alone. Players have a lot of questions. On the design end, was this the best choice? Was the issue foreseen and the decision made to go ahead anyway for whatever reason? Did ANet drop the ball? Just as some players love to design builds, others love to second-guess the devs.

It’s somewhere between lag and cost guys.

crestpiemangler.7631:

ArchonWing.9480:

Supposedly there’s technical limitations due to having to keep track of each stack on everyone, but reality suggests that 25 stacks was too easy to reach.

I just don’t think this was well planned.

It’s really insulting when I read that this is some kind of technical limitation, when WvW is a technical marvel by itself and a single PvE world boss is like the logarithm of the complexity thereof.

They ought to just be honest and say: “we want more spec diversity.” Ok, that’s fine, but if you’re going to do that in such a fashion, you have to make sure that you’re not excluding a spec entirely by default as the expected number of players rises.

This isn’t such a difficult problem to solve either. Increasing the cap to 50 for world bosses would not fundamentally change the game.

I rolled my eyes too when reading that. In any case, it wasn’t well planned and they don’t know what to do. Meanwhile, 60 people in berserker gear will do tons of more damage, but condition people… nope screw them.

ArchonWing.9480:

I rolled my eyes too when reading that. In any case, it wasn’t well planned and they don’t know what to do. Meanwhile, 60 people in berserker gear will do tons of more damage, but condition people… nope screw them.

I miss the days when people could be upfront with you and didn’t have to socially engineer a desired result….. well .. at least I miss when it was absent from my favorite hobby.

Maybe it’s the old bait and switch to make people grind for a different set of gear to make the content last longer.

crestpiemangler.7631:

locoman.1974:

AFAIK it’s not the server power that made the condition cap necessary, it’s the bandwith that’s limiting it because of the amount of data that the servers needs to receive and communicate with the clients on each tick of conditions, specially on the last leg (meaning between your ISP and your computer), which is completely out of control of Anet considering that they have to make the game playable across a wide range of connection speeds and latency.

Let’s assume that were true. Then why is it possible to concomitantly apply more than 25 conditions to separate mobs, e.g. through epidemic? It would have to use the same bandwidth, something that they are claiming is impossible for a single mob.

But those stacks need only to be communicated to the clients of whoever has the enemy targetted, not the case on (for example) world bosses where you can easily have 100+ people targetting the same enemy at the same time.

locoman.1974:

]But those stacks need only to be communicated to the clients of whoever has the enemy targetted, not the case on (for example) world bosses where you can easily have 100+ people targetting the same enemy at the same time.

Once again, you can have 100+ stacks over many different mobs and have the maximum number of people in an instance standing in the same spot, each using their own set of DoTs, which occurs quite frequently in WvW.

Again, if that were the case, then why the cap in 5 mans? … Why am I even arguing something so incredibly obvious?

WvW is the clear contradiction.

Look at it simply.

2 people and the server.

A mobs spawns, the server sends data to the two pc’s. The data that makes up the mob is now in the server’s ram and the ram of each pc.

One person applies one 10s bleed. It ticks for 10dmg every second and the mob has 100hp. So it will kill the mob eventually. The player uses the skill which sends data to the server. The server applies the condition to the mob and send data out to both clients. Both clients now see the mob with the condition and damage ticking away. This is basically 3 seperately handled occurances now. The condition timer, the 10dmg ticks, and the enemies health bar shrinking is all being processed and calculated at each client and server side simultaneously.

Now lets say that each pc has a ping of 100ms. That means there is just a oneway delay of 50ms. Since the server applies the condition to the mob and then sends the data that the condition is applied to the pc’s, the server is ahead of both pc’s by 50ms. So at the end, the mob dies and the server sends this fact out to the clients. By the time this info reaches the clients (50ms later) it gets there just in time for the mob to run out of hp on the client side and it all syncs up.

Each and every time a skill is used and an effect or change occurs to the mob, information is going to be sent. Condition stacking will be no more bandwidth demanding than auto attacking.

Deamhan.9538:

Each and every time a skill is used and an effect or change occurs to the mob, information is going to be sent. Condition stacking will be no more bandwidth demanding than auto attacking.

He is claiming that for every tick of damage dealt to a mob from a dot after application that that information is sent by the server to the client, so that dots are more bandwidth intensive than auto-attacks due to the fact that they deal damage in smaller intervals.

The curious thing about that claim, however, is that I have attacked mobs, seen the DoT tick, no damage register on the health bar for a while due to server lag and finally saw a spike in the targets health, which sort of implies what you and I have been arguing.

The devs addressed this topic multiple times.

Jon Peters addressed it here

Colin then talked about it during a four part Q&A.
The relevant quote comes from part IV

Comment and question about how conditions only stack to 25 and if you have more than one condition stacker that it becomes useless and if anything is being done to address it.

Colin: Currently, no. Interesting statistic for you – every condition in the game costs server bandwidth. We have to track how often the condition is running, what the duration of that condition is, and what the stack is at. So the more stacks we allow, the more expensive it gets because we’re tracking every additional stack on there. So, we could say that you could have infinite stacks. Number one, that becomes really imbalanced. But number two, it’s really expensive for us on a performance basis. That’s one of those weird, kind of backend server issues that can help make game design decisions regardless of what you want to do with it.

Comment and question on how if everyone has their own individual stack on a mob instead.

Colin: Yeah, it’s tough. It’s certainly something that we can look at. It does drastically change the way the professions play. It does say that you can no longer stack all of one type of condition. It might change the skills on each weapons if we were to do that. It would encourage more group play to a certain extent. It’s not really something that we’re talking about, but it’s an interesting idea.

Jon Peters posted again and then again and also brought how condition damage doesn’t affect objects

So long story short, they are aware that the current method is not the best.
How long it takes them to find a solution, and an individuals reaction to that amount of time, is up to them I guess.

Xar.6185:

So long story short, they are aware that the current method is not the best.
How long it takes them to find a solution, and an individuals reaction to that amount of time, is up to them I guess.

It’s probably not hard to find a solution, but it’s likely much harder to find one which doesn’t turn out to have glaring issues in other places/directions than the current one under testing.

To say nothing of when they use the public test, I mean, day one of the patch . . .

Xar.6185:

So long story short, they are aware that the current method is not the best.
How long it takes them to find a solution, and an individuals reaction to that amount of time, is up to them I guess.

Indeed. That’s simply not my flavor of kool-aid.

Sounds to me that they are sending unnecessary information.

You apply that 10s bleed every 2 seconds and you can stack up to 5 before the first one falls off. Each time a condition falls off, it sounds to me that it is sending data to each client when it shouldn’t have to. Each time a stack is applied, the info is sent to each client but beyond that, it can/should be handles client side. The time remaining of each stack, the dmg ticks, mob health, stacks falling off, etc. should be handled client side.

Hmm, I think I know. If you kite a mob around, it’s easy to see that there is a 1 second update delay to the mobs pathing. The server could be sending all information pertaining to the mob every second. Not just who has aggro and where it’s gonna move for the next second but health remaining, conditions applied, stacks, time left on each one. Then yeah, that would certainly make it a bandwidth monster.

Deamhan.9538:

Sounds to me that they are sending unnecessary information.

You apply that 10s bleed every 2 seconds and you can stack up to 5 before the first one falls off. Each time a condition falls off, it sounds to me that it is sending data to each client when it shouldn’t have to. Each time a stack is applied, the info is sent to each client but beyond that, it can/should be handles client side. The time remaining of each stack, the dmg ticks, mob health, stacks falling off, etc. should be handled client side.

Hmm, I think I know. If you kite a mob around, it’s easy to see that there is a 1 second update delay to the mobs pathing. The server could be sending all information pertaining to the mob every second. Not just who has aggro and where it’s gonna move for the next second but health remaining, conditions applied, stacks, time left on each one. Then yeah, that would certainly make it a bandwidth monster.

Kind of blows me away that WvW exists.

In large fights, it only exists in name.

ArchonWing.9480:

In large fights, it only exists in name.

Those fights are clearly done clientside, since GW2 servers are too fragile to handle more than 25 dots on a single mob at a time.

“Your experience is worth less to us than the cost of better CPUs. Deal with it, aholes.” -Classic ANet

Dresden.1736:

“Your experience is worth less to us than the cost of better CPUs. Deal with it, aholes.” -Classic ANet

Except I don’t think the cost is as trivial as people make it out to be . . . we’re not talking home computers, we’re talking commercial hardware. Not just once, but I-Don’t-Know how many times over. And if you want a substantial boost rather than a minimal step, we get a higher pricetag of the order of Y^X where X is the number of servers which would need upgrading . . .

Having seen at least one time a free game listed costs off about server maintenance, and upgrades, the number ain’t trivial . . . and probably shouldn’t be trivialized.

For the sake of discussion, I’m going to take it for granted that the issue is bandwidth, as ANet says it. The question I come up with is, “Knowing the bandwidth issues, why were DoT’s not treated as DoT’s are in other games, where applications of the same DoT by different players are treated separately, but individual players can only have one of the same DoT at any given time?” It’s pretty evident what the shortcomings of the current system are. It’s a lot harder to see what advantages it provides — if any.

IndigoSundown.5419:

For the sake of discussion, I’m going to take it for granted that the issue is bandwidth, as ANet says it. The question I come up with is, “Knowing the bandwidth issues, why were DoT’s not treated as DoT’s are in other games, where applications of the same DoT by different players are treated separately, but individual players can only have one of the same DoT at any given time?” It’s pretty evident what the shortcomings of the current system are. It’s a lot harder to see what advantages it provides — if any.

It was inexperience that led Anet to try to manage DoT on mobs rather than account for it by player. Other games have actually tried it but it doesn’t work. And, just thinking it through should be all that is necessary here.

The good news is that we are not hamstrung by technical difficulties. The problem is solved in other games. All you need to do is account for damage by player (damage/tick X # of ticks). That’s it. Is it doable? Yes, other games are doing it right now. Does it work? Yes, now adding 5 more condition builds to a group would be comparable to adding 5 more direct damage builds. They have acknowledged the problem and hopefully are working on the solution.

I would suggest the current visible ‘stacks’ on a boss/champ be changed to indicate the number of players with conditions applied on the boss, then each player be able to apply and maintain their own number of condition stacks applied.

In doing so, you remove the need to send full condition stack complexity to all clients, while still indicating a decent level of conditions that are actually in effect on a boss. When a single players conditions are removed/elapsed, it’s a single count decrease packet sent from the server to all clients.

For instance, the current bleeding stack might still show {8} on a boss, indicating 8 players have condition stacks applied. While you the player might see {8} with a {18} underneath indicating you have 18 stacks of bleed on this boss (or however it would be presented to the client).

Pros:

• Reduces network load significantly
• Allows many more players with any number of stacked conditions
• Increases total number of stacked conditions possible
  Cons:
• No full representation of just how many condition stacks there are. IE: you will see {8} but that might mean 8 * 1 condition, or 8 * 25 condition stacks. The {8} still gives you a good indication on what each player is doing though.

Me and another guy got in an argument over this once, and I think we’ve learned a few thing along the way. .

The biggest problem with conditions is that each one, among all of the data stored on those conditions, has to make several calculations per second for each individual stack of conditions. Upon the initial application, the condition has to constantly keep track of the variables that the player has. Namely, the condition has to reobtain both the player’s level and the player’s malice every second for every damage calculation for every condition on the enemy. It is for this reason that changes in power (via might) or changes in level affect how much damage is done in real time. Doing this every second puts a strain on the server, since the server has to constantly dig into its database to identify the player and their stats and re-preform the damage calculation each time.

Think of it like this: every time a player preforms an attack, the server has to go through a calculation to see how much damage you do. For conditions, the server has to go through a similar damage calculation for every tick of the condition. Whereas player may attack, on average, 2 or 3 times a second depending on their class, bleeds have to be calculated 25 times a second for every condition class. Combine this with 25 times for confusion, 25 times for torment, once for poison, once for burn, once for terror. The standard condition build, therefore, is actually preforming anywhere from 25 to 125 attacks per second with each bleed.

Although condition damage isn’t nearly as complex as direct damage, it is going off 50 times more frequently. When a zone starts to crash because 50 people are attacking the Claw of Jormag, well, a handful of condition builds running around the map at once could cause that much lag.

The solution to this both might be simple and it might be complicated: All you have to do is change the way conditions calculate damage. Direct damage is frontloaded and only fires off once. We should make condition damage more like direct damage: the calculation for condition damage is done once inside of the player skill, and then the damage done to an enemy would be the calculated skill damage divided by duration. Doing this would require changing the game’s code so that condition damage is handled this way (for bleeds, for example):

Condition damage becomes stored as a whole on the skill as
(0.05 Malice + 0.5 Level + 2.5) x duration

Then once applied, the damage done is
Skill damage / duration = tick damage

where the “skill damage” is a stored value that is initially held, then upon the bleed being applied to the enemy, the tick damage is decided then assigned to that particular condition. Once this tick damage is calculated, no further calculations need to be applied. It simply stores the tick damage, and applies the tick damage.

Although this adds an extra two steps in the condition application process, in the condition ticking process this is significantly less complicated, doing no additional calculations other than reducing HP, and not having to obtain player data each second.

There are some tactical changes to this method. For one, gaining might will no longer increase damage of previously applied conditions. Second, conditions applied while under might will retain their damage boost for their full duration. Third, anet will probably have to come up with a new way to calculate player “contribution” to events and kills around this new model. I suggest using 1/2 of the stored condition damage as “contribution” on each attack in PVP, and in PVE it should just be equal to the stored condition damage value.

I say this suggestion could either be simple or complicate because I don’t know how Anet has damage programmed. For all we know, the process of constantly digging into the server database to calculate damage is a necessary burden behind how they designed the system, and changing this would require changing the game’s programming from the ground up. It could be that conditions function in this manner because there is no other way for damage to function in the game. This would make the suggestion the same, in essence, to building a new game from scratch.

That said, I still think it is worth suggesting.

EDIT: Fixed a math error

EDIT: If there is a way to just maintain a tick damage once without storing the damage done in the skill itself, this can save a step or two. However, this might make calculating player contributions to kills more difficult.

IndigoSundown.5419:

For the sake of discussion, I’m going to take it for granted that the issue is bandwidth, as ANet says it. The question I come up with is, “Knowing the bandwidth issues, why were DoT’s not treated as DoT’s are in other games, where applications of the same DoT by different players are treated separately, but individual players can only have one of the same DoT at any given time?” It’s pretty evident what the shortcomings of the current system are. It’s a lot harder to see what advantages it provides — if any.

The main issue with that is the fact that it would make conditions more or less completely worthless, unless they got extremely buffed, which would make them very unbalanced.

I think a good solution would be to make conditions past the cap do direct damage or perhaps apply a different condition that isn’t affected by a cap in the same degree.

Say you are fighting a a legendary boss in a dungeon, you made the brilliant decision to bring not 1, but 2 (yes 2… what where you thinking) necromancer rocking condtionbuilds with rabid.

Now, you’re going to hit 25 stacks of bleed pretty darn fast, and it shouldn’t be much of an issue to keep it toped of most of the time.

When the boss has 25 stacks of bleed, an attack, f ex scepter 1 and 2, instead of applying bleed will do direct damage. I’m not great with numbers but I’m sure the community and / or anet can balance it. So instead of scepter 1 and 2 hitting for 200, it hits for 200 and then add damage from the bleed as direct damage.

Another thing that might work would be to apply other conditions, maybe confussion but with a longer duration (as bosses usualy hits rather slow) This could be balanced for PvE and made different for WvW / sPvP (just like retalition)

Imagine 5 conditonmancers with lots of + bleed duration nuking down a boss as fast as the mouthbreathing warriors can.

@OP
Your suggestion is worthless. You suggested to open a limit which is given by technic. Like “Build me a jetpack which can fly me to Saturn”.

There are multiple suggestion to the current condition stack issue. We (players) do not exactly know where the bottleneck is, but (I think) things could be done without flooring or OPing condition builds. But surely [Epidemic] needs to be changes. ANet seems to be very careful with this topic and we do not know if that issue landed on the wrong pile.

@ conditions are expensive
most ppl think that ANet is cheap. When Jon Peters said, that condition stacks are “expensive” it doesn’t necessarily mean “costs money”, but maybe “costs computing time” and “costs traffic”. And the term “bandwidth” usually refers to network traffic, but technically means something else. He might also refer to “cpu intensive”.

@ “there is WvW”
Now please compare the amount of (mobs + players) in an open world map and a wvw map. It’s like saying “why can’t my bicycle go 300 km/h? the train can, too”.