Support gems on Curses

"

gh0un wrote:

"

EpsiIon wrote:

All your suggestion would do is add a mandatory 2-3l devoted to curses to every serious build.

That isn't a good thing.

Are you telling me that curses right now arent mandatory?
Curses have absolutely no downside, there is no reason not to use them.
They only have benefits, so they are mandatory already.

If you dont have ubergear, chance is that you arent going to 1 shot every rare in existence without being at risk of dying.
Since most people dont have ubergear and probably will never get it, there is absolutely no reason NOT to use curses, except if you want to play a weaker version of your build.

Any serious build right now uses faster casting and increased area of affect on curses anyways, which means we already devote linked items to curses.

Curses are as mandatory as auras. Nice, yes, but no where near necessary.

Curses are no where near a mandatory 3L. Increased AoE is somewhat pointless for higher level curses, as they are more then large enough, and increased duriation isn't worth it for most people, as they kill the mobs well before normal duriation ends.

"

EpsiIon wrote:

"

gh0un wrote:

"

EpsiIon wrote:

All your suggestion would do is add a mandatory 2-3l devoted to curses to every serious build.

That isn't a good thing.

Are you telling me that curses right now arent mandatory?
Curses have absolutely no downside, there is no reason not to use them.
They only have benefits, so they are mandatory already.

If you dont have ubergear, chance is that you arent going to 1 shot every rare in existence without being at risk of dying.
Since most people dont have ubergear and probably will never get it, there is absolutely no reason NOT to use curses, except if you want to play a weaker version of your build.

Any serious build right now uses faster casting and increased area of affect on curses anyways, which means we already devote linked items to curses.

Curses are as mandatory as auras. Nice, yes, but no where near necessary.

Curses are no where near a mandatory 3L. Increased AoE is somewhat pointless for higher level curses, as they are more then large enough, and increased duriation isn't worth it for most people, as they kill the mobs well before normal duriation ends.

Well increased duration really isnt that useful, but faster casting definitely is.
If you spend less time casting curses, you are less likely to be hit before you get out of the cursing animation, which means that you cant get stunned by an enemies damage as easily, thus preventing that the stun prevents the curse from firing off.

That might actually be the only downside to curses, its´ cast time.
If you enter a room and immediately get attacked, its sometimes impossible to cast a curse without getting interrupted, thus you have to attack back in order to counterstun them.
Faster casting greatly helps with that so i would say its mandatory for curses, especially on hardcore.

"

No. It is not. Power Siphon does not work like a curse. The stats on the IIQ/IIR support gems are entirely implemented around their function, which is to apply to killing monsters. There is nothing in the game that could allow them to work on curses without substantial implementation work.

I was talking about the function of stuff triggering without the spell getting the actual killing blow.
Power siphon obviously flags enemies it hits, the duration of the flag is short, but since its there its` duration can be increased.
If that flag shows TRUE on the mobs death (or however you implemented it), it grants the power siphon user a power charge, even if he didnt get the killing blow.
This whole mechanic is already in place and it should be fairly easy to apply the same concept to other functions.

I wasnt talking about the current IIR/IIQ support gem applying to curses being already in the game at all.
However, if there is a mechanic that can enable stuff to trigger even if you dont get the killing blow, then it shouldnt be too much of a leap to create an IIR/IIQ support gem that works on curses.
The curse would then set a flag on the enemy and if the enemy dies while the flag shows TRUE, then the item rarity is applied.
Obviously i dont know how exactly you implemented curses or the support gems, or enemies for this matter, so i cant know if it is that easy to implement in your code, but i would certainly assume so given how competent you guys have shown to be thus far.

Aside from that, are you guys planning to enable other support gems for curses in the future?
I would certainly like to tinker more with my curses than just being able to increase their radius or duration, which kinda becomes dull pretty quickly.

"

gh0un wrote:

I was talking about the function of stuff triggering without the spell getting the actual killing blow.
Power siphon obviously flags enemies it hits, the duration of the flag is short, but since its there its` duration can be increased.
If that flag shows TRUE on the mobs death (or however you implemented it), it grants the power siphon user a power charge, even if he didnt get the killing blow.
This whole mechanic is already in place and it should be fairly easy to apply the same concept to other functions.

As curses do not hit anything, this might be more work thank you think.
Of course, when giving feedback, the "how much work does it take"-factor is almost irrelevant, at least to me. If you have a suggestion which you think will improve the game, you should post it. It is then upon the devs to decide whether the suggestion is good and doable.
So did I understand you right, is your suggestion to implement new support gems that mimic already existing effects from supports, but trigger on "enemy dying while cursed with supported skill"?

"

dust7 wrote:

"

gh0un wrote:

I was talking about the function of stuff triggering without the spell getting the actual killing blow.
Power siphon obviously flags enemies it hits, the duration of the flag is short, but since its there its` duration can be increased.
If that flag shows TRUE on the mobs death (or however you implemented it), it grants the power siphon user a power charge, even if he didnt get the killing blow.
This whole mechanic is already in place and it should be fairly easy to apply the same concept to other functions.

As curses do not hit anything, this might be more work thank you think.
Of course, when giving feedback, the "how much work does it take"-factor is almost irrelevant, at least to me. If you have a suggestion which you think will improve the game, you should post it. It is then upon the devs to decide whether the suggestion is good and doable.
So did I understand you right, is your suggestion to implement new support gems that mimic already existing effects from supports, but trigger on "enemy dying while cursed with supported skill"?

Not necessarily.
I just want more support gems to be enabled for curses.
I would love to be able to support a curse with the pierce support gem for example.
Enemies that are cursed would then allow your attacks to pierce according to the value on the pierce support gem.
The IIR/IIQ support working with curses would just be another application of this.

If we could tinker around with curses as we currently can with active skills, the amount of skillbuilds that are viable would be greatly increased, atleast imo.

Replying to the first post to suggest giving more support to curse.

I was thinking of quite a different thing: making curse support gems. They would only work one non-AoE gems,single target only. That would be interesting. Somethinng like Enfeebling hit :first enemy hit by the supported gem is cursed with enfeeble.

"

gh0un wrote:

"

dust7 wrote:

"

gh0un wrote:

I was talking about the function of stuff triggering without the spell getting the actual killing blow.
Power siphon obviously flags enemies it hits, the duration of the flag is short, but since its there its` duration can be increased.
If that flag shows TRUE on the mobs death (or however you implemented it), it grants the power siphon user a power charge, even if he didnt get the killing blow.
This whole mechanic is already in place and it should be fairly easy to apply the same concept to other functions.

As curses do not hit anything, this might be more work thank you think.
Of course, when giving feedback, the "how much work does it take"-factor is almost irrelevant, at least to me. If you have a suggestion which you think will improve the game, you should post it. It is then upon the devs to decide whether the suggestion is good and doable.
So did I understand you right, is your suggestion to implement new support gems that mimic already existing effects from supports, but trigger on "enemy dying while cursed with supported skill"?

Not necessarily.
I just want more support gems to be enabled for curses.
I would love to be able to support a curse with the pierce support gem for example.
Enemies that are cursed would then allow your attacks to pierce according to the value on the pierce support gem.
The IIR/IIQ support working with curses would just be another application of this.

As Mark did explain pretty thoroughly to you, you cannot "enable" support gems which work on kill or hit for curses. There would have to be completely new support gems for this.

"

As Mark did explain pretty thoroughly to you, you cannot "enable" support gems which work on kill or hit for curses. There would have to be completely new support gems for this.

Thoroughly would mean showing me the code/documentation, or explaining how exactly they coded support gems and curses (and enemies).

If they really want to do it, it would be possible, even for the current gems. You can code everything.
It might take more time to implement depending on how exactly they coded the current iterations of spell supports and curses, but its definitely possible to code, you dont necessarily need new support gems.

I am a software engineer myself, and if i can think of a solution on how to make this work with my own implementation for this, then i am sure they can aswell.
As i said though, if it isnt feasible because it would need a lot of rewriting their code, then i wont nag too much on it.

Would just have been neat to be able to use more support gems for curses.

Of course it is possible to code it but that goes against the design of those skill and support gems which is what everyone is saying.

I'm against the examples you've suggested because it's essentially adding more support gems to attack skills through curses so it can surpass the current limit of five. Not only will the game need re-balancing, it also lessen the choices players have to make with the limited number of slots and links.

"

gh0un wrote:

"

As Mark did explain pretty thoroughly to you, you cannot "enable" support gems which work on kill or hit for curses. There would have to be completely new support gems for this.

Thoroughly would mean showing me the code/documentation, or explaining how exactly they coded support gems and curses (and enemies).

Nobody is saying your suggestion cannot be coded. It just won't work in any reasonable way in the game, making the existing gems work in either illogical or unbalanced (or both) ways.

"

Mark_GGG wrote:

A Hypothetical IIQ/IIR support that worked by adding a "this drops more/better stuff" modifier for as long as a debuff created by the supported skill was in effect would work on curses, but would not work on a skill like Flicker Strike. There is no way to make one support which does both those things in a reasonable way - they are completely different effects, and thus would need to be different gems, because support gems are supposed to have consistent and understandable effects on all skills they apply to. They would also need to be balanced completely differently. The current "on kill" IIQ/IIR supports are balanced around the fact that they can never stack - a monster can only be killed by one skill, so only one of each support bonus can apply. A monster could have up to 5 curses on it, so if such a support were implemented, it would need to have significantly less effect on drops than the on-kill version.

[...]

If we want the multi-attack support gem, we'll make that, we won't change GMP to do have that as a separate effect on some skills. Same with "things debuffed by the skills drop more when they die" - that's fundamentally not what the IIQ/IIR support gems do, and if we want/need a support which does that, then we'd have to make a support which does.

Please understand now.

"

gh0un wrote:

"

EpsiIon wrote:

All your suggestion would do is add a mandatory 2-3l devoted to curses to every serious build.

That isn't a good thing.

Are you telling me that curses right now arent mandatory?
They only have benefits, so they are mandatory already.

If you dont have ubergear, chance is that you arent going to 1 shot every rare in existence without being at risk of dying.
Since most people dont have ubergear and probably will never get it, there is absolutely no reason NOT to use curses, except if you want to play a weaker version of your build.

Any serious build right now uses faster casting and increased area of affect on curses anyways, which means we already devote linked items to curses.
If you arent using curses in your build, chance is you have ubergear, or you dont have ubergear but dislike the usage of curses, which doesnt make it less mandatory for a "serious" build.

-No curses are not mandatory on a build, just like nothing else is. I've used curses as a staple in the past on some builds, the current build I'm using doesn't use them - nor does it need them.

-Just because you can't one shot something doesn't give play to it being mandatory to use curses.

Don't get me wrong, I love curses, I see there value. One of my favorite builds of all time, prior to them changing up the passive tree, was a DoT/Curse Ranger. That being said, I find that other options work better for the more recent builds that I've been playing like keeping charges going or totems down. Adding this to main attacks, putting curses into the mix would further complicate my rotations - and I feel that simplistic, well rounded rotations are just as important as anything else in a build.