Guild Wars 2

I posted some of this in another thread, but I figure this is a good enough idea that I can reprint it elsewhere. Though these solutions are simple in concept, they are not necessarily simple to execute.

#1: Bleeding.

Problem: every class and their grandmother inflicts bleeding. It makes any two condition builds in the same location redundant, because of how heavily every class depends on bleeds to do damage.

Solution: spread out the primary condition for damage out more. This will probably require inventing a new condition along the way, but for now I’ll provide a simple example: It has never made much sense to me that mesmer illusions and necromancers inflicted bleeding with their magic at a distance. It seems like this was done not as any sort of theme, but because bleeding is the default method for condition damage. What would make much more sense is if Mesmers and Necromancers, instead of doing bleeding as a default form of damage, used Torment as their default form of damage.

By relegating a class or two to dealing primarily with torment instead of bleeding, this allows other classes who inflict bleeding to work side-by-side with Condi Necros and Condi Mesmers without becoming redundant and useless.

#2: Poison.

Problem: Useless in PVE because it does low damage, stacks in duration, and enemies don’t heal.

Solution: Make it so enemies in PVE heal. We already see this done with WvW enemies. It should be the standard for anything rank veteran or higher: reduce their HP a bit, give them a healing skill. Poison reduces that healing skill by 33%, ergo poison now contributes meaningfully to PVE.

For example, if an enemy had 100,000 HP, instead give him 75,000 HP and give him a skill on a somewhat long cooldown that heals 25,000 HP. Now, that enemy will have an effective HP of 100,000, but also can be interrupted while healing and have healing reduced by poison, making it meaningful to the battle.

#3: Confusion:

Problem: It is really short duration, and slow enemy actions make it so many times it does nothing.

Solution: Don’t frontload enemies so much. Make it so enemies, on top of their infrequent high damaging attacks, have a series of quick but medium damaging attacks that are not channels or a glorified sequence of a single attack. Their big attacks will have to be reeled in a bit, but this will make it so confusion can inflict a meaningful amount of damage with its incredibly short durations, and also make it so building defensively and for support is more valuable now that dodge doesn’t stop everything.

#4: Burning:

Problem: By stacking in duration, it is quickly overwritten by other players unintentional burns, making burning a non-reliable way to do damage.

Solution: Make it so, while burning’s duration increases on a target, that burning will always retain the damage of the user with the highest malice. Whenever burning is applied, it is easy to do a quick check: Does the new guy have more or less malice? If more, then it is his burn. If less, then it just adds to the previous burn’s duration.

Hopefully, these fixes, however difficult to implement, will make it so condition classes are more potent in the game, and that the game itself will be more engaging and diverse.

/Agree

Condtions need an overhaul, to give them more sense and make the thief more important against bosses.

it was said many times why they won’t increase cap on conditions

https://forum-en.gw2archive.eu/forum/game/suggestions/Remove-the-cap-on-conditions/first#post2379446

vove.2768:

it was said many times why they won’t increase cap on conditions

https://forum-en.gw2archive.eu/forum/game/suggestions/Remove-the-cap-on-conditions/first#post2379446

Who talk about the condition cap?

Spot who didn’t read the post.

Blood Red Arachnid.2493:

Spot who didn’t read the post.

Ok than show me the line, where he wrote something about the condition cap.

Black Teagan.9215:

Blood Red Arachnid.2493:

Spot who didn’t read the post.

Ok than show me the line, where he wrote something about the condition cap.

…The irony is so thick here I think it might be intentional.

I’m the on who made the topic. I was talking about how I received a generalized condition cap response from someone who didn’t read the topic.

Give this thread a read, guy provides some interesting ideas on what to do with conditions.
https://forum-en.gw2archive.eu/forum/game/suggestions/Sollution-Condition-Stacking-Boons/first

Blood Red Arachnid.2493:

Black Teagan.9215:

Blood Red Arachnid.2493:

Spot who didn’t read the post.

Ok than show me the line, where he wrote something about the condition cap.

…The irony is so thick here I think it might be intentional.

I’m the on who made the topic. I was talking about how I received a generalized condition cap response from someone who didn’t read the topic.

The irony is that you dont understand the deeper sense behind my comments

I’m 100% behind this.

1 isn’t really any different than increasing the condition cap from the server loading point of view. You’ll simply have 25 bleeding and 25 torment instead of just upping the limit to 50.

2 and 3 are both things that would be excellent for the game on multiple levels and should probably be done.

4 would be fairly easy to “game” by stacking a single short burn and following it with several weak ones.

1: There might be, actually. A lot of people bring up the fact that torment exists as evidence that conditions work via a matrix array, wherein adding more conditions is less strenuous on an array than increasing their cap. I don’t know much about programming, so I’ll trust their theories on this matter.

1: Good to hear it.

1: I wouldn’t consider that “gaming” as much as I would “intentional function”. The whole point is that once someone has lit the fire, other people just stoke the flames. Fact is, permanent burning on an engineer is already pretty easy to obtain, and I suspect that it is also somewhat easy on Rangers and even staff mesmers. So that level of burning damage is already being done in the game.

Problem is, it is only done when a guardian or elementalist doesn’t inadvertently interrupt it. To take advantage of the intentional function, you have to already have a condition class in the team that effectively utilizes burning. This includes… Rangers and Engineers, who already light everything on fire around them.

EDIT: Darn it. Confused Matrixes and Arrays. My n00b is showing again.

have 1 stack to 50 instead of 2 conditions to 25 (especially conditions that work so differently) make a lot of difference.

also there are skills that deal more damage based on the number of conditions on enemies.

so no need to increase cap, very good to increase the number of conditions on enemy.

a long time ago, the mesmer staff could deal confusion as autoattack random condition near bleeding and burning. same the scepter and trident, so even if mobs attack happen once a year, applying it that constantly was worth something.

edit: fair is fair, why my confusion last so short and mobs confusion on me last for ever? kittenes!

@OP
Bleeding
As I’ve understood your post, you suggested for the main bleeder to cause torment instead of bleeding. And this would lower the capped bleeding for other classes since they cause bleeding without being blocked by necro and mesmers bleeding ?

Well, seems interesting but has three flaws.

• Making them torment would boost ehm in pvp/ wvw but nerf them on PvE. And this would result in a balancing patch to reduce it’s total efficiency (since devs balance in PvP means) so PvE gets a double nerf.
• Making another stack with 25 torments would sure stress the server more than right now.
• It wouldn’t take care of the problem, but slightly push it back. Two necros in a party would still reach the cap and on world bosses, both caps would easily be full.

Poison
PvE mobs fairly often use regeneration. And here again, ANet balances for PvP … all conditions could be buffed in PvE, but they’re pretty strong in PvP. So we won’t get a change.

Confusion
And here again. Confusion was really bad in PvE and fairly strong in PvP. So as balancing they nerfed it in PvP.

Burning
Good suggestion, but have you read the mechanics of duration stacking conditions? What you suggested is already ingame. And even better, it doesn’t only priorize on infliction but on every tick. So buffing yourself (might) might put your burning first. Once you lose the buffs, another burning might get ticks then.

Bleed:
Solved by: The max stack stays at 25 but the stacks you put on belong to you.
How to: Add an array that counts the amount of stacks per person.

Poison:
Solved by: Increasing PvE damage
How to: Change the modifier from 0.10 to something else
+Add an array that counts the amount of stacks per person.

Confusion:
Solved by: Having more enemy attacks hit with confusion
How to: Increase the confusion time in PvE matching players and enemy attacks.
+Add an array that counts the amount of stacks per person.

Burning:
Solved by: Making the time you put on an enemy belong to you.
How to: Add an array that counts the amount of seconds per person.

Nretep.2564:

@OP
Bleeding
As I’ve understood your post, you suggested for the main bleeder to cause torment instead of bleeding. And this would lower the capped bleeding for other classes since they cause bleeding without being blocked by necro and mesmers bleeding ?

Well, seems interesting but has three flaws.

• Making them torment would boost ehm in pvp/ wvw but nerf them on PvE. And this would result in a balancing patch to reduce it’s total efficiency (since devs balance in PvP means) so PvE gets a double nerf.
• Making another stack with 25 torments would sure stress the server more than right now.
• It wouldn’t take care of the problem, but slightly push it back. Two necros in a party would still reach the cap and on world bosses, both caps would easily be full.

Poison
PvE mobs fairly often use regeneration. And here again, ANet balances for PvP … all conditions could be buffed in PvE, but they’re pretty strong in PvP. So we won’t get a change.

Confusion
And here again. Confusion was really bad in PvE and fairly strong in PvP. So as balancing they nerfed it in PvP.

Burning
Good suggestion, but have you read the mechanics of duration stacking conditions? What you suggested is already ingame. And even better, it doesn’t only priorize on infliction but on every tick. So buffing yourself (might) might put your burning first. Once you lose the buffs, another burning might get ticks then.

The bleeding thing is a pretty complicated suggestion. It won’t just be a straight up conversion of bleeds = torment. Ultimately, things will be scaled for PVP, and because in PVP torment is equal to 1.5 bleeds, necromancers will lose 33% of their bleed duration on all bleeds that are converted to torment.

This in itself can be a mixed bag. For one, there are enemies that move around a lot, so a necomancer can maintain full offense against enemies so long as they just cripple/chill and kite. Condi necros in PVE will require more activity this way. The second thing is that, currently, condition necromancers are incompatible with every other condition build in the game sans guardians. This means that there a very steep drop in offense should two of them ever collide, and this happens a lot. With the torment fix, necromancers won’t have nearly as much as an incompatibility problem, and this results in an increase in damage for the class in group scenarios..

Overall, this will (hopefully) result as a buff for conditionmancers and condi mesmrs. The server itself will receive more stress since there are more stacks of torment around, but in theory the servers already deal with this stress whenever enough torment users come together.

The goal of this fix is for smaller scale groups and dungeons. World bosses will always be impossible to fight with condition damage, so long as they take conditions. Other than a straight up condition to damage conversion on the bosses (a suggestion that they’ve heard a thousand times, no doubt), there is no fix that won’t overtax the servers.

The suggestions for poison and confusion can be roughly summarized as “make PVE better and more engaging”. The effects they themselves have is fine. It is just that PVE is built in a way that these effects never take place.

If burning behaves like this, then it is good news. I could’ve sworn I’ve seen my burning on my condi engi overwritten by other classes, though. Maybe they changed that already.

Blood Red Arachnid.2493:

The bleeding thing is a pretty complicated suggestion. It won’t just be a straight up conversion of bleeds = torment.
[…]
currently, condition necromancers are incompatible with every other condition build in the game sans guardians. This means that there a very steep drop in offense should two of them ever collide, and this happens a lot.
[…]
Overall, this will (hopefully) result as a buff for conditionmancers and condi mesmrs.
[…]

Basically what you are suggesting is “make each class get their own kind of bleeding which doesn’t stack with the others”. So two necros wouldn’t work together, but multiple classes would. This wouldn’t solve the problem, but increase the stress. This way you could also say “increase the stacks to 100”.
And for condition mesmers … no need to care. They deal their bleeding by critting, which is not possible on most world bosses. The bleedings come from other classes.

Blood Red Arachnid.2493:

The goal of this fix is for smaller scale groups and dungeons. World bosses will always be impossible to fight with condition damage, so long as they take conditions. Other than a straight up condition to damage conversion on the bosses (a suggestion that they’ve heard a thousand times, no doubt), there is no fix that won’t overtax the servers.

I’ve already made suggestions which would work. They wouldn’t overpower it (except epidemic), would probably lower the stress, encourage teamplay and anyone can do their condition damage. In short, turn the 25 stacks/ 30s duration (once reached) into direct damage and remove the stacks. Ofc this would need some attention with torment now (suggested it before torment), probably poison and confusion. But removing those full stacks and exchanging them for direct damage would still be better in 95% of the cases.

Blood Red Arachnid.2493:

The suggestions for poison and confusion can be roughly summarized as “make PVE better and more engaging”. The effects they themselves have is fine. It is just that PVE is built in a way that these effects never take place.

As I said, the ANet balancing team may not even know that there’s PvE in the game …

Blood Red Arachnid.2493:

If burning behaves like this, then it is good news. I could’ve sworn I’ve seen my burning on my condi engi overwritten by other classes, though. Maybe they changed that already.

Poison, too. I’d expect the same for chill, cripple, blind, immobilize and weakness, but like it matters there. But there’s damaging fear … no clue.

The idea behind giving different classes their own basic form of condition damage is that it is much easier for the server to handle than just increasing the cap. Why? Don’t know. It must have something to do with programming, since without some knowledge on the subject I don’t see the wisdom of introducing torment at all. I don’t know jack about what an array is in game design. Regardless, there is a precedent for this, and continuing this precedent is not unreasonable. Regardless, if you get enough torment users in an area then the server already experiences the amount of stress that my suggestion would impose. So, it is safe to assume that the servers can handle what I am suggesting.

You must also realize that there is far more issues with conditions than on just environment world bosses. There are plenty of champions and bosses who allow crits, such as every temple boss in Arah. There are also all of the bosses in dungeons who aren’t environmental objects.

Thankfully Arenanet is already making the enemies more engaging. Molten Facility and Aetherblades has demonstrated that the content designers are more than capable of making more engaging content, and the AI for WvW guards and the AI enemies in the mists, everything I’ve suggest has not only been done before, but is getting better. The real hope behind this is that the PVE team will go over enemies from pretty much every part of the game and make them more engaging.

The ironic thing is that I am not sure if your suggestion would go well in PVP, unless it was a mechanic reserved only for overworld bosses, champions, veterans, and silver rank mobs.

Blood Red Arachnid.2493:

The idea behind giving different classes their own basic form of condition damage is that it is much easier for the server to handle than just increasing the cap. Why? Don’t know.
[…]
Regardless, if you get enough torment users in an area then the server already experiences the amount of stress that my suggestion would impose. So, it is safe to assume that the servers can handle what I am suggesting.

As I said, your suggestion would equal to “make bleeding stack to 50”. In terms of additional damage and in terms of additional server stress.
It’s not “can handle”, but “going in the wrong direction”. Because what you’re suggesting is a minor patch only delaying the main issue by creating more server stress. Since the issue will not be solved, others will suggest the same then. Create an additional condition to get its own stack. Then you again delay the problem and increase the server stress. And then again … That’s why it’s equal to “make bleeding stacks bigger”.

Blood Red Arachnid.2493:

It must have something to do with programming, since without some knowledge on the subject I don’t see the wisdom of introducing torment at all. I don’t know jack about what an array is in game design.

Actually, the current system already includes arrays. The “common array suggestion” (making arrays → use multi dimensional arrays) would just explode the server stress.
To explain it … assuming the application of each condition is indepent to any other (so not the tick based theory). Each boss (mob) has its array of bleedings, meaning it has 25 reserved slots for bleeding with duration and (player) source. Once those 25 are filled, the server continuously has to check if any of those actually ticks, recalculate the dealt damage, reduce their remaining duration and replace them once a new bleeding is applied.
Now the “common array suggestion” would mean instead of 25 bleeding stacks, each mob would have 25 slots each player. So on world bosses with 25 players, it’d equal 625 (25×25) bleeding slots, which have to be managed just like the current 25.

If the current system is tick based (second theory of players), it’d be basically the same, but the server only checks once a second once the first tick based condition is applied. It’d still increase the server stress (computing and transmitting) by 25.

Blood Red Arachnid.2493:

You must also realize that there is far more issues with conditions than on just environment world bosses. There are plenty of champions and bosses who allow crits, such as every temple boss in Arah. There are also all of the bosses in dungeons who aren’t environmental objects.

Don’t mix yellow bosses with buildings. You can crit buildings, but can’t put conditions on them. Yellow world bosses are the opposite. But I do have multiple characters with “on crit” builds, which is kinda awkward there.

Nretep.2564:

As I said, your suggestion would equal to “make bleeding stack to 50”. In terms of additional damage and in terms of additional server stress.

And as I said, I’m not sure that is true. I’ve heard mention that arrays have an easier time adding more entries than increasing their limits, so when compared to simply increasing the cap, this is a superior option. For this, I am not sure whether there is an individual array for each player, since that does sound like it will explode the server.

The thing that I am unsure about is why it is torment would be superior to a higher cap in the first place. There is a bit I do know about programming, and also from what I’ve heard about the devs on the issue, and from that it seems counter-intuitive:

Every condition that is applied needs to keep track of several things. It’s duration, it’s stack, it’s damage, and its user. Using this information, we can identify how many bits are necessary to hold this information:

Duration: the duration of conditions is divided into quarter seconds. Now, I have never heard of a duration “cap”, so to speak, but I also haven’t seen any condition stack its duration for higher than a minute. But, lets just assume that the duration cap is two minutes. This would be 120 × 4 = 480 different values for the remaining duration. Data is stored in games as bits, with 8 bits equal to a byte. Each byte integer increases the storage capacity by a factor of 8, so two bytes can hold 64 different values. This means that, to contain the duration of the condition, it would need 3 bytes (maximum of 512 values).

Damage: this is a function of malice that just has an equation done to it. So, malice can go pretty high, but myself have never seen malice exceed 3000 points. This would require 4 bytes (4096 values) for raw data. In this, I do not know how the equation to calculate damage is stored.

Stack: This is a simple integer up to 25, so two bytes will suffice.

Identity: This is a kittene, since it requires a lot of guess work. I would assume that each character in the game has a hidden ID number that is generated for them. How many values there are for this ID number, I don’t know. If I were to guess, I’d say 6 bytes is more than enough to contain all character IDs, having 262k values per server.

Each of these together comes to 15 bytes of information, checked every quarter second (the duration of conditions in the game is divided as such). A full set of bleeds would require 25 × 15 = 375 bytes per check, and at 4 times a second this comes to 1.5 Kilobytes per second. This can be much faster if conditions are checked by the game tick rate instead of the condition duration listing. I do not know what the game tick rate is, however if I were to just guess at it being around 0.125 seconds or so, then this would come to 3 Kilobytes per second for a full stack. Combine this for every enemy in the map, and you can potentially have a massive amount of data being processed.

This is where my perplexity comes in. From my understanding of bytes, although it would require more processing, simply increasing the stack limit to upwards of 64 wouldn’t increase the number of bytes stored in any conditions. There wouldn’t be any reason why it is that adding new conditions would be superior to just increasing the cap. And yet, this is exactly what Anet has done.

So, assuming that Anet knows their own programming, and assuming that Anet factored in two necros with epidemic entering the same room together (all that is needed to get 24 stacks of torment), then there must be some programming reason why it is Anet has decided that new conditions were better that is superior to my gameboy understanding of programming. Since Anet has given the O.K. for more conditions while shooting down the concept of increasing the cap, then this solution would be satisfactory to improve the game.

Blood Red Arachnid.2493:

Every condition that is applied needs to keep track of several things. It’s duration, it’s stack, it’s damage, and its user. Using this information, we can identify how many bits are necessary to hold this information:

Condition damage is not stored in the condition itsself. Each time it ticks, the player’s current malice will be computed again. e.g. if you inflict 10s burning and get one might after five seconds, the remaining 5 (/4) ticks will be of higher value. This also influences the priorization order of duration stacking effects.

Blood Red Arachnid.2493:

Duration: the duration of conditions is divided into quarter seconds.

Wrong again. Only the tool tip rounds to the nearest quarter. The duration itsself will be “precise”. e.g. 1s burning + 10% conduration = 1.1s burning while only 1s is displayed.
http://wiki.guildwars2.com/wiki/Condition_Duration

Blood Red Arachnid.2493:

Now, I have never heard of a duration “cap”, so to speak, but I also haven’t seen any condition stack its duration for higher than a minute.

Each players condition duration is capped at + 100%.
But I’ve also heard that burning is capped to 30s … not sure here. Maybe it’s also capped at 25 sources.

Blood Red Arachnid.2493:

But, lets just assume that the duration cap is two minutes. This would be 120 × 4 = 480 different values for the remaining duration. Data is stored in games as bits, with 8 bits equal to a byte. Each byte integer increases the storage capacity by a factor of 8, so two bytes can hold 64 different values. This means that, to contain the duration of the condition, it would need 3 bytes (maximum of 512 values).

Your understanding of bits and bytes seem off.

A byte usually contains 8 bits, indeed. But it doesn’t mean a byte can hold 8 different values. A byte can hold 256 (2^8) different values and two bytes 65536 (2^16). But this doesn’t matter here.

The problem shouldn’t lay in the storage needed, but the processing time or traffic size. The traffic one should be obvious, but would wouldn’t explain some things. I mean, the server calcs the remaining HP and has to transmit it to anyone, regardless of the number of conditions.
So let’s talk about the computing stress. Imagine you have 30 sources of burning on a single boss. So each tick the server has to go through each burning entity, check the source (player), calculate its current malice (can change anytime), select the highest one and apply the single tick of burning. Pretty much the same for bleeding except that every bleeding deals damage.
And now do this for every condition for every mob on the server. And then imagine you do this for as much attacking players there are.
And then you’ve to deal with replacing bleedings … does it really cap or will weaker ones be replaced? Not sure if anyone has tested this yet. We’re really missing test golems in LA which can be inflicted with conditions and last longer than 10s.

Nretep.2564:

Condition damage is not stored in the condition itsself. Each time it ticks, the player’s current malice will be computed again. e.g. if you inflict 10s burning and get one might after five seconds, the remaining 5 (/4) ticks will be of higher value. This also influences the priorization order of duration stacking effects.

I didn’t say that damage was stored in the condition itself. I said that damage is done as a function of malice, and malice is stored as a certain number of bytes. I also said didn’t know how much data is needed to process the damage equation.

Nretep.2564:

Wrong again. Only the tool tip rounds to the nearest quarter. The duration itsself will be “precise”. e.g. 1s burning + 10% conduration = 1.1s burning while only 1s is displayed.
http://wiki.guildwars2.com/wiki/Condition_Duration

The link you provided says nothing to the effect of what you claim and provides no evidence either way. There is a problem with this, though: the duration of conditions cannot be precise because it has a precision limit hard built into the game. This precision limit is the game refresh rate, or how many ticks per second the game has.

Nretep.2564:

Each players condition duration is capped at + 100%.
But I’ve also heard that burning is capped to 30s … not sure here. Maybe it’s also capped at 25 sources.

Not player duration buffs. Individual condition durations. The longest “player skill” condition listed is 1 minute, from Tooth Stab, a stolen skill from thieves. The longest duration for a condition that a player can get from skills comes from Blood is Power at 100% duration, which is also 1 minute in length. It is for this reason that I think the duration cap might be around 1 minute, but nonetheless calculated for 2 minutes under the assumption that even though it isn’t displayed, Tooth Stab gets an increase in duration as well.

Nretep.2564:

And then you’ve to deal with replacing bleedings … does it really cap or will weaker ones be replaced? Not sure if anyone has tested this yet. We’re really missing test golems in LA which can be inflicted with conditions and last longer than 10s.

The replacement system works on an “oldest out, newest in” system, regardless of any statistical advantage one my have over the other.

Nretep.2564:

The problem shouldn’t lay in the storage needed, but the processing time or traffic size. The traffic one should be obvious, but would wouldn’t explain some things. I mean, the server calcs the remaining HP and has to transmit it to anyone, regardless of the number of conditions.

The interesting thing is, the equations used to calculate conditions are really simple. Duration is handled by the build beforehand, and once applied the game just needs to reduce the duration via in-game clock. Stack order is probably just a flag applied to stacking conditions that checks if a previously applied condition has disappeared yet. Player identity is a static value applied to the condition based on who used it.

The big part of the traffic comes from HP and the damage the condition inflicts. The computer would have to check the player identity flag, refer to that player’s stats (malice and level), preform a calculation based off of their current malice and level, subtract that from the enemy’s HP, an do this calculation at least one a second. It is here that most of the processing takes place.

This does raise a question, though. Whenever a player does direct damage, it has to update the enemy’s HP and then send that information back t every player within range. Direct damage doesn’t have a pacing cap at all, so when you have 50 players all attacking a single champion, firing off 2 attack per second or so, then the champion has to calculate the damage done (involving random integers, weapon strength, power, precision, crit damage, enemy toughness, check for protection and weakness, etc), and it has to do this 100 times a second.

Enemy HP calculation must not be too complicated, since there isn’t anything done to limit work load from direct damage vs. every enemy in a zone, and it without any rate limit to them. I wonder if they can improve the condition system by reworking how thy are run, factoring the condition as a function of static damage inflicted by a player each second, instead of attaching the condition to the monster.

The best way to change conditions is to make them all stack based on duration, with each player getting their own unique stack.

Bleeding now does more damage the longer it lasts. Each person’s stack of bleeding does its damage on its own individual timer.

Burning remains as is, but each person gets their own stack.

Poison remains as is, but each person gets their own stack.

Confusion doesn’t really need to be changed, but could be reworked into a duration condition with reworked numbers.

Torment is fine as is, but could also be reworked into a duration condition with reworked numbers.

My thought on how to clean up some of these issues, which is covered in much more detail in another thread is to boil all the condition damage down to a single stack per player and let the damage accumulate over time.

Each condition should have a fixed duration (my rough starting thoughts based on relative GW1 scaling are Bleed – 8s, Poison – 6s, Burning – 3s) these values would be universal for all instances of these conditions. The conditions would be applied as a raw damage number (1200 flat bleeding damage for example as opposed to 12 ticks @ 100 damage each), and they would get spread across the time window for that condition. If a new instance of a condition is applied, you’d take whatever damage remained from the previous iteration and roll it into the new application, and re-spread that number across the same fixed time window. Each person would have their own instance of those conditions, but only 1 ‘stack’ to manage per person. Condition cleanses would have to remove all instances of that specific condition.

From a math and tracking standpoint, you’ll basically need to keep track of the owner and 2 numbers per condition: Damage = D and Remaining Time =T
When adding new condition damage C to the current stack or creating a first stack from 0:
D1 = D0 + D
T1 = Tmax for the condition type
Ticks = D1/T1
Every second on the tick:
D1 = D0 – D0/T0
T1 = T0 – 1

So in this case, the conditions would all stack in both intensity and duration to some extent because of the rolling nature of the damage.

Blood Red Arachnid.2493:

I didn’t say that damage was stored in the condition itself. I said that damage is done as a function of malice, and malice is stored as a certain number of bytes. I also said didn’t know how much data is needed to process the damage equation.

Not quite. Malice is not stored in the condition itsself, the owner is. In terms of coding it is a big difference:
For each condition stack

1. If remaining duration <= 0; remove condition; don’t continue
2. get playerid
3. get players current malice
4. calculate tick damage
5. reduce remaining duration
6. apply tick damage

If you’d store the condition damage or malice in the condition itsself, you wouldn’t have to check the malice for each tick from one of the players. I don’t know how efficient the player code is, but getting the malice from a player ID (#3) should have a higher stress than probably all other steps.
Technically, I’d insert the condition’s damage into the stack. This would mean an applied bleeding wouldn’t change its damage “live”. Instead it’d use the damage you had when you applied the bleeding. This would encourage timed infliction when you’re buffed, but discourage buffing while your conditions are applied. It should reduce the stress by quite a bit.

Blood Red Arachnid.2493:

the duration of conditions cannot be precise because it has a precision limit hard built into the game. This precision limit is the game refresh rate, or how many ticks per second the game has.

Not all games work in “tick based computing”. But yeah, every digital system has a limit in precision, that’s no secret.

Blood Red Arachnid.2493:

The interesting thing is, the equations used to calculate conditions are really simple.
[…]
Player identity is a static value applied to the condition based on who used it.

“Simple” is an interesting word. For the computer there’s noting “simple” or “difficult”. The equation “looks” simple, but you still need to compute it. Let’s have a look at it …
(0.05 * Condition Damage) + (0.5 * Level) + 2.5

two multiplications and three additions. A single ALU (single math unit within a PU) would need like (2×4 + 3×1) = 9 cycles to compute a single tick … assuming all constants would be present at time. Using simple commands, it’d be like

1. clear ALU
2. load 0.05 in ALU
3. get malice from playerID
4. multiply malice to ALU
5. store ALU in slot x
6. clear ALU
7. load 0.5 in ALU
8. get level from playerID
9. multiply level to ALU
10. add slot x to ALU
11. add 2.5 to ALU
12. store ALU in slot x

Barely anyone coded in this depths, but this is what the CPU has to do. The italic lines are complex functions. You need to check the livePlayerDB for the ID and get another column as result. And this assuming you don’t have to recalculate the malice from level, equip, traits and buffs.
Imagine a single line to need 1 cycle, the italic lines at 5 cycles (way to low) and multiplications at 3 cycles and you get 24 cycles just to calculate the condition damage … now insert it in the code I wrote above … so far for “simple calculation”.

Blood Red Arachnid.2493:

The big part of the traffic comes from HP and the damage the condition inflicts. The computer would have to check the player identity flag, refer to that player’s stats (malice and level), preform a calculation based off of their current malice and level, subtract that from the enemy’s HP, an do this calculation at least one a second. It is here that most of the processing takes place.

Substracting the total life shouldn’t be that difficult. And for the traffic, I don’t know the netcode. I don’t see other players’ damage, so I only see mine and the boss’ HP value. I also don’t know how often it’s refreshed. I don’t think it’s necessary to refresh it more than twice a second (for pvp). That’s why I don’t think it’s a traffic issue, but I’m not common with netcode.

Blood Red Arachnid.2493:

Whenever a player does direct damage, it has to update the enemy’s HP and then send that information back t every player within range. Direct damage doesn’t have a pacing cap at all, so when you have 50 players all attacking a single champion, firing off 2 attack per second or so, then the champion has to calculate the damage done and it has to do this 100 times a second.

You are right. But when 30 players deal direct damage at 1x per sec, it’s still only 30 calculations per second. You additionally have to calculate multiple conditions, at least 25 bleedings. Imagine any necro attack it gets 1 direct damage and 4 bleeding damage ticks. The caps are chosen to allow direct damage and condition damage.

Nretep.2564:

Not quite. Malice is not stored in the condition itsself, the owner is. In terms of coding it is a big difference:

I didn’t say malice was stored in the condition itself. I said malice was stored. We all know it is playerside.

Interesting thing though: I wonder why conditions check the malice of the player in the first place? Why can’t each condition just go off of the malice from when it was applied, and keep a static amount of damage regardless of what happens to the player? The more we talk about this, the more I think the condition bandwidth problem is a product of bad programming.

Regardless, by simple calculations I am referring to the fact that condition damage is done through just multiplication and addition. I’ve encountered games before (like runescape) that used a series of logarithmic formulas to calculate things such as damage and defense, requiring more computing power to come up with a result.

Nretep.2564:

Not all games work in “tick based computing”. But yeah, every digital system has a limit in precision, that’s no secret.

I am almost certain that this game uses it, since the game requires a constant uplink to a server that processes things.

Nretep.2564:

Substracting the total life shouldn’t be that difficult. And for the traffic, I don’t know the netcode. I don’t see other players’ damage, so I only see mine and the boss’ HP value. I also don’t know how often it’s refreshed. I don’t think it’s necessary to refresh it more than twice a second (for pvp). That’s why I don’t think it’s a traffic issue, but I’m not common with netcode.

It isn’t just about enemy HP. The actual function of damage has to check several things to take place:

Player Power
Weapon Strength
Skill coefficient
Random number to determine the damage done through the power scale
Player Crit chance
Random Number to determine if an attack is a critical hit
Player Crit damage
Check for Weakness
Random number to determine if weakness takes effect.
Check for Vulnerability
Multiply by Vulnerability coefficient
Check for protection.
Multiply by protection coefficient.
Check for Procedural effects (procs)
Apply those procedural effects.
Identify Player that inflicted damage (done for reward balancing in events and stuff)

And this has to take place on every single hit. This means that skills that hit multiple times, such as Unload or LIfe Transfer, in theory would cause an immense load on the system.

I suppose the reason why they would limit conditions would be because an individual player could put a high server load by themselves by just running a condition build. The flip side to this is that this is only true when condition builds are spread out and attacking different enemies. When engaging the same enemy, where the caps limit DPS the most, condition builds contribute very little to the server-side lag that is experienced in these events. Fact is, when I cap conditions on a champion while I’m by myself, the entire zone doesn’t start skill-lagging and freezing up.

Load reduction might be a reasonable explanation for why so many bosses are treated like environmental objects with conditions enabled. No precision means no crits, no procs.

If they removed the need to constantly update conditions with player malice, and instead made conditions static upon application, I get the feeling that this would optimize the system greatly. I can’t think of any balancing reasons why this wouldn’t be done.

I’d prefer if they just added a few abilities that ate condition stacks for bonus damage when they cap either stacks or duration. That would be a smaller change, though I’m probably not thinking through the pvp result of that too clearly; but you can just take it off the menu there.

-turn over flow bleed into ground effect area
-turn OFB into allied but not owned pet (blood golem, sharks, leeches)
-OFB procs random debuff (there’s blood in my eyes! all this blood sure is slippery!)
-OFB procs aoe buff (delcious)
All sorts of options

Blood Red Arachnid.2493:

Interesting thing though: I wonder why conditions check the malice of the player in the first place? Why can’t each condition just go off of the malice from when it was applied, and keep a static amount of damage regardless of what happens to the player? The more we talk about this, the more I think the condition bandwidth problem is a product of bad programming.
[…]
If they removed the need to constantly update conditions with player malice, and instead made conditions static upon application, I get the feeling that this would optimize the system greatly. I can’t think of any balancing reasons why this wouldn’t be done.

As I said before, I’d also agree to static condition damage (once applied), if it’d reduce the stress by a noticeable amount (and let’s them increase the stack size), but that was most likely a design choice, not a bad programming.

If you alone fight a mob as guardiang and manage to stack up 20s of burning (by various means), buffing yourself (12 might) makes your (previously applied) ticks stronger. Unfortunately it also requires “live” “resorting” on duration stacking effects. I don’t think it’s necessary, but it’s a design choice.

Blood Red Arachnid.2493:

Regardless, by simple calculations I am referring to the fact that condition damage is done through just multiplication and addition. I’ve encountered games before (like runescape) that used a series of logarithmic formulas to calculate things such as damage and defense, requiring more computing power to come up with a result.

Yeah, you can separate maths operations in terms of “complexity” when computing on CPUs (different for GPUs) and things like log, root and factorials should lead the list. But there’s still a difference in “calculating once the equipment is changed” (ragnarok online’s way) and “calculate each tick of conditions”. I don’t know how malice is calculated each tick, but a single attack might inflict 10s bleeding on 3 enemies causing 30 (10?) recalculations of bleeding damage, while a single logarithmic version could only be calculated once and plied 30 times.

Blood Red Arachnid.2493:

And this has to take place on every single hit. This means that skills that hit multiple times, such as Unload or LIfe Transfer, in theory would cause an immense load on the system.

As I observed multihit skills, they only calculate the damage for one hit and reapplied it for the remaining. e.g. rangers burst shot vs non-crit targets. The first hit randomed 111 damage, so the remaining hits deal 7×111 damage. But yeah, they crit individually and trigger so and so on.

Blood Red Arachnid.2493:

Fact is, when I cap conditions on a champion while I’m by myself, the entire zone doesn’t start skill-lagging and freezing up.

That’s the way with netcode. You don’t know how much is processed on the client side.

Blood Red Arachnid.2493:

Load reduction might be a reasonable explanation for why so many bosses are treated like environmental objects with conditions enabled. No precision means no crits, no procs.

As I said before, don’t mix dragons and buildings. dragons are immune to crits and buildings immune to conditions.
But generally yeah. Server stress might be an explanation for disabling crits on dragons. The penalize condition and crit builds. So favoring direct damage really is their thing.

So they chose to use bad programming as a design choice. The big question now is what the design choice was intended to be used for. Took a shower and thought about it, and I have an idea.

The only thing I can really come up with is that the game was designed with this as a form of assigning participation and “credit” to things like kills and events. It is no secret that the reward you receive for dynamic events is proportional to how much damage you inflict divided by how long you were in the event range. A reason for the constant re-assessing of malice might be that, in order to give an extremely precise metric for contribution in any kill or event, the damage that each condition inflicts is treated as an individual “hit” that constantly refers back to the player who applied the condition. Thus, through the dynamic nature of combat having cleanses and overwritten conditions, a player who objectively contributes little with conditions due to these factors would receive a “fair” compensation as far as things go.

That is the only reason I can think of that doesn’t immediately suffer from an arbitrary logic fail on my part. Even the above listed reasoning can fall short, due to debate as to what would be “fair” in that regard. I’ve considered a couple of things, and each one doesn’t make for a good design choice:

#1: Making conditions do more or less damage than direct damage when influenced by might. Unfortunately this one is largely moot, since applying conditions then gaining might isn’t much different from gaining might then applying conditions.

It’s a bit hard to explain, but think of it like this: Throughout combat there is a certain threshold T that is how many bleeds are sustained on the opponent. This is equivalent to the frequency they are applied F times their duration D divided by their recharge R. Might has itself a certain window of usage which I will call W. In the current system, might affects everything prior and during its window then ceases, so the damage increase from might is TW. With a static system, the window affects conditions applied, and them remains active on those conditions throughout their duration, so it is FDW. As it happens, FD forms a certain fraction of the sustained conditions in which might’s window takes effect, and this fraction is determined by dividing by the recharge R. This ends up being T again, so ultimately the static system produces TW like its counterpart.

The only condition that could be considered abusable by this mechanic would be burning. Bleeds stack individually, poison is barely present and used for anti-healing properties, confusion doesn’t have long enough duration to take advantage of, and torment stacks individually. With the way burning works, a player could stack might, apply burning, and so long as they maintain burning duration they will never lose power from that burning. This has pros and cons, though, since it is very easy to lose burning duration in combat, and this isn’t completely superior to stacking might whenever you can with current burning benefiting from that.

This is important, since burning is the only condition where a static system would behave differently from how might acts with direct damage. Might isn’t retroactive on direct damage, so making conditions static just evens out the discrepancy between the two with how might behaves.

#2: Reducing tactical application of conditions. Something wrong with my equation for #1 is that conditions aren’t applied at a set frequency. For Necros, Rangers, and Mesmers their conditions can and usually are applied in bursts. This makes it so it is tactical to apply might, then burst on conditions while under might, just like with direct damage.

The fault in logic is that a static system is more tactical, not less. With this dynamic system, you just throw on conditions whenever and gain might whenever, then might does its thing. With a static system, gaining might would signify an incoming burst, allowing countermeasures to be used. You could steal or strip might, reducing their bust. You could bunker up and block/dodge the conditions that you know are coming. You could reserve a full cleanse for that moment, rendering their offense moot. Your opponent could anticipate the cleanse then attempt to stun lock you so you can’t use it. Etc. and so on.

#3: They don’t want conditions to be bursty. There is this design ideology Anet has that condition classes should all be gradual. The problem is that condition burst already exists, but just in a matter that doesn’t involve risk vs. reward.

The big thing here is that by requiring might before inflicting conditions, this makes it so the condi build has to take a risk. They have to get in close, blow their cooldowns in this window, and withdraw. Things can go wrong from there. The dynamic system is risk-less: use conditions whenever, then once conditions are applied and things have gone right, then you can stack might while kiting and turtling up, inflicting more damage while being defensive at the same time.

Having conditions change with might doesn’t reduce the potency at all. Conditions linger, so stacking might after things go right still causes the same amount of burst as stacking conditions after might, where things can go wrong.

In the end, player credit is the only reason that doesn’t doesn’t fall apart when it looks in a mirror. The incremental build of credit due to the nature of conditions is something you can’t argue against in itself, since any alternate options can be exploited or result in an unfair application. The second big question is this: Is it worth it to have an imperfect player credit system in order to reduce lag and improve conditions in the game?

My answer is hell yes. I probably have to go and make another thread about this, since this thread’s current suggestion has become obsolete in light of new reasoning.

As I said, making malice dealing “live” damage is a design choice.

#1
I assume the developers wanted a dynamic combat system, which usually implies the current system. And at the same time, it is less abusive. Imagine you had a source of 25 might stacks for a single second. You could use it and burst “all” (lol, casttime) your condition skills to deal max damage even after the buff. The current system would be fairer and only grant you one second full damage.

#1-2
I’m not sure if they actually make the duration increase or just add one stack. Adding a single stack works better, since it has to be done anyways with multiple players. Making an actual duration increase would lower the stress, indeed.
But assuming it is implemented as different stacks (like bleed), your problem doesn’t matter for any system. If they’d implement a static condition damage system, you’d apply three stacked burnings with different damage and duration properties, which are applied one after another (strongest first), just like when using multiple ppl right now.

Confusion also stacks in intensity.

#2
As I said before. A system with static condition damage would encourage timed condition infliction (buff and then use your skills) but also discourage untimed buffing (why buff when the condition is already applied). It’s also very difficult to time your buffs with your teammates, assuming you use a static system. A dynamic one would work on both.

#3
Imagine you’d see your opponent flee from you (PvP) with tons of conditions and you can’t catch up, just might yourself.

Genrally
As I said multiple times right now, both systems have advantages and disadvantages. It’s just a choice of the developers to use the dynamic version. And designs shouldn’t be limited by technical implementation.
But I’d still prefer a 35 stack static system than a 25 stack dynamic system. Especially since both have their own advantages.

And as I said, it was a design choice to be a bad programming choice. You’ve got to learn that just because I’m responding to something or don’t agree doesn’t mean I didn’t read it.

#1: Two things. First, this is the equivalent to how might works for direct damage: get 25 stacks of might, use Kill Shot or Backstab, do all the damage at once even in one second. This change would simply make it so conditions are equivalent to direct damage in this regard, so it presents very little of a balance issue. Bleeds still have to tick away slowly to do damage. They can still be cleansed. Difference is, when you see a necromancer coming at you with 25 stacks of might, you know to dodge for that second because they’re gonna burst conditions. Or to save your cleanse to nullify that big condition burst. Second, might doesn’t behave that way in the game.

#1-2: I forgot to mention that confusion also stacks in intensity. No one is perfect. I’m not sure if burning is sequential or sustained, either. I know that sustaining mechanics exists, since the Engineer has one on their flamethrower kit.

#2-3: The advantage here that timed condition infliction and timing buffs has that it is tactical, and it would behave just like direct damage behaves now. It won’t be some big, new, scary mechanic players have never seen before that kills strategy. Non-condition builds already deal with the exact same scenarios I’ve described. The #3 point also illustrates the lack of tactics on the matter: for the running player there is no play in having the condition source stack might when they aren’t around. If a condition build wanted to accomplish the same effect, they could’ve just stacked might before applying a ton of conditions, then the opponent would be dead if they ran anyway in the first place.

Genrally, the big problem with all of the “advantages” to the dynamic system is that they encourage thoughtless spamming and lazy tactics that aren’t necessarily superior to the static system, and eat up a lot more bandwidth to accomplish this. Every venue I went down while thinking about the design philosophy that Arenanet has, as well as what would make sense from a strategy and depth increasing standpoint has kept toppling every argument I could possibly postulate for the presence of dynamic conditions.

Being a design choice doesn’t mean it wasn’t a bad choice, either. From how much the game has changed from beta (AKA their initial design choice), it is very clear that Arenanet made bad choices to begin with.

Burning has stacks just like bleeding does. They cap at 25, just like bleeding. The stacks just tick sequentially rather than concurrently.

Air blast doesn’t add duration to an existing stack, it just adds an additional stack if burning is already up.

This part is important:

Burning stacks DO NOT tick in the order of highest damage to lowest. They seem to be First In First Out for normal circumstances, although I haven’t tested enough to know how the over 25 stacks situation is handled.