stickupkid
Dalayan Beginner
Currently as we all know two bards cannot stack any detrimentals and they always overwrite eachother without looking at which bard has the higher mod.
That the debuff songs not stack is wanted and fine because you could just mega debuff mobs otherwise, but for the second bard its a pretty big loss to not be able to use his relic chant. As the concern is the debuff part and not the damage dealing part of the song I was hopin that there could be a way to make at least the damage dealing parts stack with eachother, while using the debuff part only from the higher modded bard if there is a difference. This could be achieved by splitting up the chants into two components where the debuff part is 2nd spell which is autocasted once the chant is landed on the mob.
At the moment im not in the situation that I have step back on my songs, but I been in this position before and its frustrating not to be able to play all your songs because you are the less geared/tomed bard in the raid/group - and that you have to pay close attention not to overwrite your fellow bards songs.
For groups where dps of the single person counts more this would having 2 bards be way less of a dps tradeoff as it often is now. The problem is that when 2 bards are in the same group/raid, that the second bard loses a substantial amount of his "standalone dps".
The other suggestion I have is to add a check when two bards try to cast the same detrimental on the mob and give the higher modded song a higher stacking priority so it doesnt get overwritten. It doesnt happen so often, since all bards know that if they have the lower mod that the other bard is on the duty to play, but still there are some situations where its really disturbing that whoever casted last gets his song to stick. For example: Modded beneficial songs like po4/regen or chants when 2 bards play it (usually by accident) or when 2 bards use the pbae dot to hit more targets but then the dots of the higher damage bard gets overwritten on some of the mobs.. same with the ae snare etc.
Hope this could be looked at some day, when there is some time on the dev's hands.
That the debuff songs not stack is wanted and fine because you could just mega debuff mobs otherwise, but for the second bard its a pretty big loss to not be able to use his relic chant. As the concern is the debuff part and not the damage dealing part of the song I was hopin that there could be a way to make at least the damage dealing parts stack with eachother, while using the debuff part only from the higher modded bard if there is a difference. This could be achieved by splitting up the chants into two components where the debuff part is 2nd spell which is autocasted once the chant is landed on the mob.
At the moment im not in the situation that I have step back on my songs, but I been in this position before and its frustrating not to be able to play all your songs because you are the less geared/tomed bard in the raid/group - and that you have to pay close attention not to overwrite your fellow bards songs.
For groups where dps of the single person counts more this would having 2 bards be way less of a dps tradeoff as it often is now. The problem is that when 2 bards are in the same group/raid, that the second bard loses a substantial amount of his "standalone dps".
The other suggestion I have is to add a check when two bards try to cast the same detrimental on the mob and give the higher modded song a higher stacking priority so it doesnt get overwritten. It doesnt happen so often, since all bards know that if they have the lower mod that the other bard is on the duty to play, but still there are some situations where its really disturbing that whoever casted last gets his song to stick. For example: Modded beneficial songs like po4/regen or chants when 2 bards play it (usually by accident) or when 2 bards use the pbae dot to hit more targets but then the dots of the higher damage bard gets overwritten on some of the mobs.. same with the ae snare etc.
Hope this could be looked at some day, when there is some time on the dev's hands.
Last edited: