YandereGirlfriend wrote: »No change is better than a bad or hastily made change. No-Proc Ravenwatch burned that hard wisdom into my brain.
And we absolutely should NOT be "testing changes on Live" as some have suggested.
Let them cook without pressure and return with something simple and targeted that actually solves the problem. Because there is no magic number tweaking that can make the original design of the change acceptable, it is irredeemably flawed approach.
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi everyone,
First, thanks to everyone for providing so much feedback in this thread, and especially for those that were able to hop on the PTS this week to try out this change in real time. We’ve heard your feedback loud and clear – both from this thread and other sources – and we’d like to let you know we are planning to revert the Heal over Time on Battlespirit in next week’s PTS patch.
For additional context, the initial reasoning behind this change was to help with a common complaint we’ve seen over the years that healing feels too strong, most notably with stacked HoTs. Transparently, we simply don’t have the time or bandwidth to fully change healing capabilities without significantly affecting future class reworks, which is why we landed with this option, but it clearly missed the mark.
We’ll explore other options to address concerns around healing and damage shields in PvP to be released in a future update, and we’ll share some ideas prior to it hitting the PTS so you can be more involved in the process. Thanks again for sharing your thoughts here, and again, you can expect the revert to occur in next week’s PTS patch.
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
The_Meathead wrote: »Cut HoTs and Shields down to one of each kind, and don't overthink a solution into something that will impact non-BGers potentially every bit as much or (invariably) more than the BGers.
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
MeridiaFavorsMe wrote: »These healing changes feel stupid. You seem to be trying to target the most optimized 12 mans, but all the proposed changes will be disproportionality hitting people that are playing small scale groups.ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
These healing changes feel fundamentally misdirected. The stated goal appears to be curbing highly optimized 12-man groups, but both options you’ve outlined disproportionately punish small-scale and outnumbered play instead.
A flat hot-based healing penalty barely impacts large groups, because their survivability comes from stacking mitigation, hots, shields, and burst healing—not simply raw hot uptime. Meanwhile, small groups and solo players rely on hots to survive being outnumbered, since they don’t have the luxury of constant cross-heals, shields, or coordinated ultimates, huge numbers of targets to spread out the damage.
Reducing the modifier to 33% doesn’t solve this problem; it just makes the penalty less extreme while still applying it to the wrong players. Increasing the hot threshold to 5 similarly misses the point—small-scale builds frequently hit that number just to stay functional under pressure, while ball groups will still comfortably operate above it.
In practice, these changes lower the skill ceiling for coordinated groups while lowering the survivability floor for everyone else. That pushes Cyrodiil further toward burst-or-be-bursted gameplay, which historically leads to less counterplay, less build diversity, and less reason to engage when outnumbered.
If iteration is the goal, then the current hot-count modifier isn’t a good foundation to iterate on. It doesn’t meaningfully target the behaviors causing performance or balance issues, and instead erodes one of the few tools small-scale PvP still has to function in Cyrodiil.
Just reduce the amount of times vigor, regen and shields can stack. Simple. There is no need for echoing vigor to stack a million times and there’s no need for overall healing, whether you’re solo or in a group, to be affected depending on a variable outside of your control
Teeba_Shei wrote: »MeridiaFavorsMe wrote: »These healing changes feel stupid. You seem to be trying to target the most optimized 12 mans, but all the proposed changes will be disproportionality hitting people that are playing small scale groups.ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
These healing changes feel fundamentally misdirected. The stated goal appears to be curbing highly optimized 12-man groups, but both options you’ve outlined disproportionately punish small-scale and outnumbered play instead.
A flat hot-based healing penalty barely impacts large groups, because their survivability comes from stacking mitigation, hots, shields, and burst healing—not simply raw hot uptime. Meanwhile, small groups and solo players rely on hots to survive being outnumbered, since they don’t have the luxury of constant cross-heals, shields, or coordinated ultimates, huge numbers of targets to spread out the damage.
Reducing the modifier to 33% doesn’t solve this problem; it just makes the penalty less extreme while still applying it to the wrong players. Increasing the hot threshold to 5 similarly misses the point—small-scale builds frequently hit that number just to stay functional under pressure, while ball groups will still comfortably operate above it.
In practice, these changes lower the skill ceiling for coordinated groups while lowering the survivability floor for everyone else. That pushes Cyrodiil further toward burst-or-be-bursted gameplay, which historically leads to less counterplay, less build diversity, and less reason to engage when outnumbered.
If iteration is the goal, then the current hot-count modifier isn’t a good foundation to iterate on. It doesn’t meaningfully target the behaviors causing performance or balance issues, and instead erodes one of the few tools small-scale PvP still has to function in Cyrodiil.
This is basically why Vengeance sucks as a campaign. Without good cross-healing and AoE, you can’t fight outnumbered. The bigger group always wins, and it’s super boring.
This seems to be what the iterative process is pushing toward. The real problem is that people are never prepared to fight ball groups, while ball groups are always prepared to fight anything. With the latest changes allowing respecs anywhere, this may change, but it isn’t even being given a chance to see if it’s going to work.
Just reduce the amount of times vigor, regen and shields can stack. Simple. There is no need for echoing vigor to stack a million times and there’s no need for overall healing, whether you’re solo or in a group, to be affected depending on a variable outside of your control
Exactly this.
Balls would be forced to "bring" more healing to their comp if cross healing was limited. Literally only a few skills like vigor, radiant, conti or burst. Puts a hard on how much it can scale, forces more healing into comps to survive, without affecting those below the cap. Ball groups will find a way around anyway, but this is a healthier step forward.
CameraBeardThePirate wrote: »Teeba_Shei wrote: »MeridiaFavorsMe wrote: »These healing changes feel stupid. You seem to be trying to target the most optimized 12 mans, but all the proposed changes will be disproportionality hitting people that are playing small scale groups.ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
These healing changes feel fundamentally misdirected. The stated goal appears to be curbing highly optimized 12-man groups, but both options you’ve outlined disproportionately punish small-scale and outnumbered play instead.
A flat hot-based healing penalty barely impacts large groups, because their survivability comes from stacking mitigation, hots, shields, and burst healing—not simply raw hot uptime. Meanwhile, small groups and solo players rely on hots to survive being outnumbered, since they don’t have the luxury of constant cross-heals, shields, or coordinated ultimates, huge numbers of targets to spread out the damage.
Reducing the modifier to 33% doesn’t solve this problem; it just makes the penalty less extreme while still applying it to the wrong players. Increasing the hot threshold to 5 similarly misses the point—small-scale builds frequently hit that number just to stay functional under pressure, while ball groups will still comfortably operate above it.
In practice, these changes lower the skill ceiling for coordinated groups while lowering the survivability floor for everyone else. That pushes Cyrodiil further toward burst-or-be-bursted gameplay, which historically leads to less counterplay, less build diversity, and less reason to engage when outnumbered.
If iteration is the goal, then the current hot-count modifier isn’t a good foundation to iterate on. It doesn’t meaningfully target the behaviors causing performance or balance issues, and instead erodes one of the few tools small-scale PvP still has to function in Cyrodiil.
This is basically why Vengeance sucks as a campaign. Without good cross-healing and AoE, you can’t fight outnumbered. The bigger group always wins, and it’s super boring.
This seems to be what the iterative process is pushing toward. The real problem is that people are never prepared to fight ball groups, while ball groups are always prepared to fight anything. With the latest changes allowing respecs anywhere, this may change, but it isn’t even being given a chance to see if it’s going to work.
Healing isn't the reason you can't fight outnumbered in Vengeance; the reason you can't fight outnumbered in Vengeance is because of AoE damage caps.
If Vengeance was exactly the same as it is now, but you removed the target cap for all AoE damage abilities, you'd instantly have way more ability to bomb large groups. AoE Damage caps prevent you from coordinating an ult dump with your group, because instead of everyone damaging the same group of enemies, the game decides that you all damage different enemies and no one dies.
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
CameraBeardThePirate wrote: »The_Meathead wrote: »Cut HoTs and Shields down to one of each kind, and don't overthink a solution into something that will impact non-BGers potentially every bit as much or (invariably) more than the BGers.
Important to note that shields are already limited to one of a kind, and furthermore, the limit applies to the base skill, meaning that even 2 different morphs of the same shield cannot stack.
Shielding will need a bigger change to nerf it. Large groups rely on 4 primary shields; Contingency, Chakrams, Barrier, and Arcanist's Bubble ultimate. There are other shields that are also large offenders, such as Soul Burst and Wield Soul, but these shields are slightly less efficient and thus not as commonly used.
The best route to nerfing shields is to either 1) reduce each subsequently stacked shield by a percentage, so that each shield you stack is weaker than the last, or 2) cap the total shielding amount of a player to a % of their health, rather than having a cap for each individual shield (as it doesn’t matter that an individual shield caps at 60% of a target's health when 3 can be combined to double or triple someone's healthbar).
For option 2 I could see Ultimate sourced shields being exempt, but given that Barrier is one of the largest offenders in Ball Groups, something needs to give.
Your best bet is a cap on each of the problematic hots (echo and radiating, potentially funnel health and the scribing secondary script hots). Reduced healing from having too many hots is completely nonsensical and unintuitive because it still puts supports in a position where getting involved weakens your own team.ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5
ZOS_GinaBruno wrote: »Hi all, thanks for the continued feedback provided in this thread. We recognize that many of you would still like to see this issue addressed – we do too! – and reverting this change doesn’t mean we are shelving it. Again, this first try was exactly that – it was a first try and just didn’t land. This is all part of development being a bit more fluid moving forward and allowing us the space to iterate and try different things.
We do still plan to revert this change which you’ll see in next week’s PTS patch, but in the spirit of iteration and talking through options, here are a couple options (it would need to be one or the other) we may be able to explore for Update 49:There are a lot of good suggestions in this thread, but realistically, many require time-consuming code changes and bandwidth is currently very tight with everything else the team is working on. Also keep in mind any options we lay out for Update 49 don’t and won’t prevent us from considering a longer-term option later. We are definitely open to discussing a short-term solution, though, and are interested to hear what you think of the two options presented above.
- We could reduce the 50% modifier to a lower value, such as 33%
- We could increase the number of HoTs it takes to trigger the modifier, maybe to 5