Guild Wars 2

(Because people would prefer arguing back and forth instead of a creative discussion, I’ve taken this and made it it’s own thread)

The main technical limitation to conditions (trouble finding the red post of it, if someone has a link to said post, it’d be apreciated) is the amount of processing power needed each second (I believe). Take the triple trouble wurm heads during phase 2 as an example. On a successful map, you generally have up to 50 people there at each head. (we’re going to disregard build logistics for a bit) That means you’re going to have 50 people applying bleeds of various lengths, with various levels of might, various levels of corruption stacks, and various other buffs. At minimum you’ve got 200 different calculations per second, assuming bleeds and might stacks are gained/losted in 1 second intervals. We all know this isnt true, and those things can happen as fast as 4-5 times a second, now you’re looking at 1000 or more calculations per second. Same thing happens with poison, burning, and torment. That’s about 3000 calculations (and this is being overly simplified) per second at a single head. There’s 3 in the fight. That’s 9000. There’s also trash mobs in the fights, so we’ll double the number on a conservatively “low” side, then round it off. 20,000 calculations per second. I’d say that’s a pretty definite technical limitation as a result of the ‘at present’ method of condition damage.

Now, what if condition damage was ‘fixed’? You’d reduce the number of calculations by a lot. For example, instead of calculation condition damage every second, what if the damage was calculated based on your stats at the moment of application? This alone cuts the number of calculations from as little as 50% (2 seconds of damage) to as much as 98% (60 second bleeds, blood is power). If anet does that, it opens up some processing power to add some much needed finesse to conditions. For example, if there’s already 25 stacks of bleed on a target and, assuming condition stacks would be sorted by potency (stack 1 weakest, stack 25 strongest), they would be able to change the system so that for each incoming stack of a condition, it checks to see if the potency (for simplicity this is the dps value) is greater than the lowest current stack (stack 1). If it’s not higher, the condition is ignored. If it is higher, the current stack 1 is purged and replaced with the incoming stack, then conditions are resorted appropriately.

Some of the downsides would, obviously, be that in fights where might is not regularly maintained, players will see more up and down values to their conditions applied. On the flip side however, condi builds, and to an extent hybrid builds, should see an improvement to their condition damage, as the above changes would assign priority to their conditions over the junk conditions applied by their party members once caps are reached.

Finally, a further change that can be instituted shortly after the above changes, is a modular condition cap for enemies in PvE. Suggested changes involve the following:

• ‘regular’ enemies encountered in dungeons (basic, veteran, elite) retain current cap limits
• Champions and mid-bosses in dungeons (like Lupi or spider queen as examples) have their cap increased by 40% to a total of 35 stacks
• End bosses in dungeons have their cap increased by 100% to a total of 50 stacks
• Open world champions have their cap increased by 20% to 30 stacks total
• Open world Meta event bosses have their caps increased by 100%, 200%, or 300% (50, 75, or 100 stacks) according to boss tier
• Additional changes with above: Epidemic will only apply X stacks of conditions from the targeted enemy to the surrounding enemies, where X is each surrounding enemy’s cap

As should be obvious, this is not to be confused with any of the other existing condition threads nor merged with them as the suggestion involved is not a duplicate of any thread.

Hmm that is VERY interesting, and I could actually seeing it work. However, I think the main issue would be coding such a thing. I am not super experienced in coding, but I wouldn’t even know where to begin. It would also mean a complete restructuring of the whole condi system. Something that is going to take a long long time, and not an easy fix. For all we know they started working on something similar back in the first part of launch, and are still working on it. Thats why we haven’t seen a “fix” to the whole system.

I am sure the devs are well aware of how the current system, although a good idea, just isn’t quite working. I don’t believe they are ignoring it either. But time will tell.

Ideally it’d use most of the coding structure in place already. The main difference is that instead of running the damage calculation every second (or more often), it’s called at the moment of application, then the result is stored in a hash/array pair. Then every second, it’s simply a call to the stored information to get the damage amounts.

So if I’m understanding correctly. The amount of total damage due to bleeds is automatically applied at application, but the system would simply divide it according to how many stacks have been applied, and the amount of condi damage the applier has?

Something like:
X= total condi damage (Amount of damage per stack * number of stacks)
Y= Number of stacks
Z= Condi duration

X / Y * Z?

So if I used say, Blood is power on my necro (which does a total of say 16,000 damage over 1 min with 6 stacks of bleed.) It would take 16,000 divide it by 6 (2666 per stack, 44 damage per second) and stretch it out over 1 min. So the 16,000 damage is calculated at application, but the damage per stack per second is stored and recalled as needed instead of doing the calculation on the fly.

I hope I got that right….

Possibly right, so I’ll explain it a bit more the way I think it would work. Right now, it’s common knowledge that the bleeding condition deals 43 damage minimum at level 80 with a {43+(condition damage*coefficient)} formula. This means at a base, BiP’s displayed damage is 2550 bleeding damage via 2 stacks over 30 seconds. Assuming the three following situations, here’s how the system would work:

• 1: 0 stacks of bleed on target. Casting BiP and not losing the might instantly (between boon application and condition application), results in a 60 damage per stack per second for bleeds. While this increases the displayed skill text, the skill text is more or less ignored. This is because the condition damage is calculated when applied, so when the two stacks of bleed are applied, the following happens:
  43+17 (simplifying the math for now) condition damage for stack 1 @ 30 seconds
  43+17 condition damage for stack 2 @ 30 seconds
  call sort with arguments ‘condition damage’ (basically once you’re done applying conditions, it sorts them by ascending damage)
  (no stacks of bleed/torment/etc, or few enough stacks that what you’re applying does not exceed the cap, stacks added without issue)
• 2: 25 stacks of bleed @ X seconds for 43 condition damage on target. Casting BiP and not losing the might instantly. Due to less open stacks than what is coming in, the following happens:
  43+17 condition for stack 1a @ 30 seconds
  IF stack 1a.conditiondamage > stack 1.conditiondamage, THEN stack 1 = stack 1a
  43+17 condition for stack 1b @ 30 seconds
  IF stack 2a.conditiondamage > stack 2.conditiondamage, THEN stack 2 = stack 2a
  call sort […]
  (full stacks (or not enough open space) calculates the condition damage, then overwrites the lowest existing stack if the new damage is higher, repeats for each stack applied by a skill, then sorts)
• 3: 25 stacks of bleed @ X seconds for 43 condition damage on target. Casting BiP and losing the might instantly (no might at condition application. Due to less open stacks than what is coming in, the following happens:
  43 condition for stack 1a @ 30 seconds
  IF stack 1a.conditiondamage > stack 1.conditiondamage, THEN stack 1 = stack 1a, ELSE ignore
  43 condition for stack 1b @ 30 seconds
  IF stack 2a.conditiondamage > stack 2.conditiondamage, THEN stack 2 = stack 2a, ELSE ignore
  call sort […]
  (same as #2 except due to the condition damage being the same (or lower) than the lowest existing stack, the condition is ignored entirely)

Once that is done, it recalls the condition damage for each stack (60/60 in #1 and #2) and supplies that to whatever algorithm or subsystem manages damage as input instead of the current {43+(condition damage*coefficient)} formula.

tldr: in a nutshell, you’re correct. It would allow classes like necros that have the combination of might+offensive condition to reduce some of the rampup time. Using that skill as an example, if you open with BiP, that gives you 12 seconds to inflict bleeds at an increased damage level that, after 12 seconds, remains at that increased damage level.

In part, this is essentially how FFXIV handles DoTs. The rest of it is a matter of having a larger DoT cap and trying to avoid content that attracts big enough zergs to run into it.

I assume that there is some reasoning behind why the devs didn’t make things like condition damage snapshot, but I’ve never heard what it is.

My personal instinct would be to count up total damage over time amounts, so that e.g., a stack of bleed appears for every 7% of your hp that you’re about to lose to bleeding.

However, that risks playing havoc with condi removal (I guess it would have to remove a stack at a time?), damaging the distinction between burning and bleeding, and gets weird with conditions that aren’t pure damage or that punish certain acts, such as confusion, torment, poisson, and terror.

Aidan Savage.2078:

Possibly right, so I’ll explain it a bit more the way I think it would work. Right now, it’s common knowledge that the bleeding condition deals 43 damage minimum at level 80 with a {43+(condition damage*coefficient)} formula. This means at a base, BiP’s displayed damage is 2550 bleeding damage via 2 stacks over 30 seconds. Assuming the three following situations, here’s how the system would work:

• 1: 0 stacks of bleed on target. Casting BiP and not losing the might instantly (between boon application and condition application), results in a 60 damage per stack per second for bleeds. While this increases the displayed skill text, the skill text is more or less ignored. This is because the condition damage is calculated when applied, so when the two stacks of bleed are applied, the following happens:
  43+17 (simplifying the math for now) condition damage for stack 1 @ 30 seconds
  43+17 condition damage for stack 2 @ 30 seconds
  call sort with arguments ‘condition damage’ (basically once you’re done applying conditions, it sorts them by ascending damage)
  (no stacks of bleed/torment/etc, or few enough stacks that what you’re applying does not exceed the cap, stacks added without issue)
• 2: 25 stacks of bleed @ X seconds for 43 condition damage on target. Casting BiP and not losing the might instantly. Due to less open stacks than what is coming in, the following happens:
  43+17 condition for stack 1a @ 30 seconds
  IF stack 1a.conditiondamage > stack 1.conditiondamage, THEN stack 1 = stack 1a
  43+17 condition for stack 1b @ 30 seconds
  IF stack 2a.conditiondamage > stack 2.conditiondamage, THEN stack 2 = stack 2a
  call sort […]
  (full stacks (or not enough open space) calculates the condition damage, then overwrites the lowest existing stack if the new damage is higher, repeats for each stack applied by a skill, then sorts)
• 3: 25 stacks of bleed @ X seconds for 43 condition damage on target. Casting BiP and losing the might instantly (no might at condition application. Due to less open stacks than what is coming in, the following happens:
  43 condition for stack 1a @ 30 seconds
  IF stack 1a.conditiondamage > stack 1.conditiondamage, THEN stack 1 = stack 1a, ELSE ignore
  43 condition for stack 1b @ 30 seconds
  IF stack 2a.conditiondamage > stack 2.conditiondamage, THEN stack 2 = stack 2a, ELSE ignore
  call sort […]
  (same as #2 except due to the condition damage being the same (or lower) than the lowest existing stack, the condition is ignored entirely)

Once that is done, it recalls the condition damage for each stack (60/60 in #1 and #2) and supplies that to whatever algorithm or subsystem manages damage as input instead of the current {43+(condition damage*coefficient)} formula.

tldr: in a nutshell, you’re correct. It would allow classes like necros that have the combination of might+offensive condition to reduce some of the rampup time. Using that skill as an example, if you open with BiP, that gives you 12 seconds to inflict bleeds at an increased damage level that, after 12 seconds, remains at that increased damage level.

Too Much Math Didn’t Read: I suppose that could be a fairly effective solution. It would also make condi damage food that much more valuable and effective. Lets just hope the devs are at least considering this as a possibility, or even some variation of this plan that doesn’t require re coding the whole game to accomodate :P

Less recoding the whole game than recycling what’s useful, and adding in coding to make conditions still not suck, which even with the calculation changes, still wouldnt change for the most part. Some sort of priority system should be in place.