Jump to content

[Bug] - Lifebloom final heal coef - Rev. 8099


Auntie Mangos

Recommended Posts

  • 39 years later...

MaNGOS/0.14.0 (* * Revision 8099 - 10cff43e042a2f2b9701821f980c0e738ce910c5) for Linux_x32 (little-endian)

Using script library: ScriptDev2 (for MaNGOS 8078+) Revision [1190] 2009-06-30 12:49:08 (Unix)

Using World DB: UDB 0.11.5 (381) for MaNGOS 8029 with SD2 SQL for rev. 1141

Using creature EventAI: ACID 0.1.0 - Full Release

Lifebloom

Heals the target for 371 over 7 sec. When Lifebloom completes its duration or is dispelled, the target instantly heals themself for 970 and the Druid regains half the cost of the spell. This effect can stack up to 3 times on the same target.

Everything exept the final healing its fine here (When Lifebloom completes its duration or is dispelled, the target instantly heals themself for 970).

The HoT is enhanced by 9.5% of your spell power per stack per tick. The bloom is enhanced by 64.6% of your spell power.

--> http://www.wowwiki.com/Lifebloom can you take a look to that ^^

Link to comment
Share on other sites

  • 2 weeks later...

Also, the final bloom is not being multiplied by the number of stacks. Quoting 3.1.0 patch notes:

Lifebloom: Mana cost of all ranks doubled. When Lifebloom blooms or is dispelled, it now refunds half the base mana cost of the spell per application of Lifebloom, and the heal effect is multiplied by the number of applications.
Link to comment
Share on other sites

Also, the final bloom is not being multiplied by the number of stacks. Quoting 3.1.0 patch notes:

Correct me if i'm wrong, but according to the wowwiki's patch notes and to wowhead's comments it works as intended.

Patch 2.1.0 (2007-05-22): Each additional application of this spell will now include the full bonus from effects which increase healing. The final heal, however, is still unaffected by stacking multiple applications of this spell.
Link to comment
Share on other sites

I believe patch 3.1.0 is more recent than patch 2.1.0 =)

That's true, i do agree, but that doesn't mean that that part of spell functionality has changed since then. I would highly appreciate if someone who can test it on offy will tell us how it works with current or any other recent patches. Ty. ^^

(Still, assuming that blizzard nerfed it couple of times, i don't think they will amplify it this way. It would be too overpowered in my opinion, but that's just my humble presumtion. :P)

Link to comment
Share on other sites

o.O

It's quite clear on the patch note that they changed it, imho:

Patch 2.1.0:

Each additional application of this spell will now include the full bonus from effects which increase healing. The final heal, however, is still unaffected by stacking multiple applications of this spell.

Patch 3.1.0:

Lifebloom: Mana cost of all ranks doubled. When Lifebloom blooms or is dispelled, it now refunds half the base mana cost of the spell per application of Lifebloom, and the heal effect is multiplied by the number of applications.

But yeah, perfect scenario would be if anyone could test it.

EDIT: Just found this comment on wowhead (link):

(...)

lifebloom got two major changes with the patch:

1) double mana cost but refunding 490 mana per stack when blooming.

2) the bloom stacks, creating potential 14k+ crit blooms

(...)

Link to comment
Share on other sites

So here is the code that is risponsible for the "blooming" part of the spell. (SpellAuras.cpp, dummy auras handler)

...
                   // final heal
                   if(m_target->IsInWorld() && m_stackAmount > 0)
                   {
                       int32 amount = m_modifier.m_amount / m_stackAmount;
                       m_target->CastCustomSpell(m_target, 33778, &amount, NULL, NULL, true, NULL, this, GetCasterGUID());

                       if (caster)
                       {
                           int32 returnmana = (GetSpellProto()->ManaCostPercentage * caster->GetCreateMana() / 100) * m_stackAmount / 2;
                           caster->CastCustomSpell(caster, 64372, &returnmana, NULL, NULL, true, NULL, this, GetCasterGUID());
                       }
                   }
...

Is it just me or the amout should be multiplied rather than divided by the stack amount? :huh:

(assuming that the blooming effect stacks)

Link to comment
Share on other sites

                        int32 amount = m_modifier.m_amount / m_stackAmount;
                       m_target->CastCustomSpell(m_target, 33778, &amount, NULL, NULL, true, NULL, this, GetCasterGUID());

replace by:

                        m_target->CastCustomSpell(m_target, 33778, &m_modifier.m_amount, NULL, NULL, true, NULL, this, GetCasterGUID());

Link to comment
Share on other sites

                        int32 amount = m_modifier.m_amount / m_stackAmount;
                       m_target->CastCustomSpell(m_target, 33778, &amount, NULL, NULL, true, NULL, this, GetCasterGUID());

replace by:

                        m_target->CastCustomSpell(m_target, 33778, &m_modifier.m_amount, NULL, NULL, true, NULL, this, GetCasterGUID());

Does anyone know if the spell power coefficient is supposed to be multiplied per stack as well? (For anyone wondering, the spell_bonus_data being used is direct_bonus for the Lifebloom spell that is cast, not the triggered spell 33778)

Link to comment
Share on other sites

the bloom need to be multiplied per stack like 970x3 with 3 stacks, and that number is used to the get the finla coeficients bases on you spell power...

for example with 1500 spell power should be something like this...

970x3=2910

1500*64.6/100=969

2910+969=3879

so in this case shoulder heal 3879 (no crit) when it blooms...based on 1500 spell power, doesn't matter what talents you have, because the bloom can't be affected with talents chance, just the hot...

this is how lifebloom works, should i post an screen or something to verify what i say?

Link to comment
Share on other sites

Assuming you coefficient is right the SQL modification would probably look something like:

-- Updating coefficients for Lifebloom Final Heal
DELETE FROM `spell_bonus_data` WHERE `entry` IN (`33778`);
INSERT INTO `spell_bonus_data` (`entry`, `direct_bonus`, `dot_bonus`, `ap_bonus`, `comments`) VALUES
(`33778`, `0.646`, `0`, `0`, `Druid - Lifebloom Final Heal`)

On a side note someone should post a patch in the under review section with all the code etc so the patch isn't forgotten.

Link to comment
Share on other sites

Assuming you coefficient is right the SQL modification would probably look something like:

-- Updating coefficients for Lifebloom Final Heal
DELETE FROM `spell_bonus_data` WHERE `entry` IN (`33778`);
INSERT INTO `spell_bonus_data` (`entry`, `direct_bonus`, `dot_bonus`, `ap_bonus`, `comments`) VALUES
(`33778`, `0.646`, `0`, `0`, `Druid - Lifebloom Final Heal`)

On a side note someone should post a patch in the under review section with all the code etc so the patch isn't forgotten.

Look more closely at the code; I said that the spell_bonus_data being used should not be that of the triggered spell 33778.

if ( apply )
               {
                   if ( caster )
                       // prevent double apply bonuses
                       if(m_target->GetTypeId()!=TYPEID_PLAYER || !((Player*)m_target)->GetSession()->PlayerLoading())
                           m_modifier.m_amount = caster->SpellHealingBonus(m_target, GetSpellProto(), m_modifier.m_amount, [b]SPELL_DIRECT_DAMAGE[/b]);
               }

This basically stores the direct_bonus in the m_modifier.m_amount of the HoT effect of the lifebloom, then

m_target->CastCustomSpell(m_target, 33778, &[b]m_modifier.m_amount[/b], NULL, NULL, true, NULL, this, GetCasterGUID()); 

uses the already calculated bonus.

Edit: The reason for this instead of just using 33778 is because 33778 is SPELL_DAMAGE_CLASS_NONE: it will not benefit from spell power by itself.

Link to comment
Share on other sites

Edit: The reason for this instead of just using 33778 is because 33778 is SPELL_DAMAGE_CLASS_NONE: it will not benefit from spell power by itself.

Great, now we also know why the blooming part doesn't crit! Here's a code snippet that should provide a hint. ;)

(Unit.cpp, Unit::isSpellCrit function)

bool Unit::isSpellCrit(Unit *pVictim, SpellEntry const *spellProto, SpellSchoolMask schoolMask, WeaponAttackType attackType)
{
   // not critting spell
   if((spellProto->AttributesEx2 & SPELL_ATTR_EX2_CANT_CRIT))
       return false;

   float crit_chance = 0.0f;
   switch(spellProto->DmgClass)
   {
       case SPELL_DAMAGE_CLASS_NONE:
           return false;
       case SPELL_DAMAGE_CLASS_MAGIC:
...

Can you tell me how you've obtained the information about 33778's damage class? In other words where damage classes for spells are stored?

Link to comment
Share on other sites

Great, now we also know why the blooming part doesn't crit! Here's a code snippet that should provide a hint. ;)

Can you tell me how you've obtained the information about 33778's damage class? In other words where damage classes for spells are stored?

Wow, good observation!

You can look in the \\contrib\\dbcEditer\\bin\\ folder for something to view Spell.dbc with. Just look for the DmgClass column.

Link to comment
Share on other sites

Hmm, to fix this, we have to understand why blizz assigned SPELL_DAMAGE_CLASS_NONE to the damage class of Lifebloom's and Haunt's healing parts rather than SPELL_DAMAGE_CLASS_MAGIC. Or why developers of mangos have chosen to skip the calculation of spell healing bonus and spell critical chance for this damage class.

For now i see just two solutions: to add checks for these spells into Unit::isSpellCrit() and Unit::SpellHealingBonus() or to add calculation of spell critical chance and spell healing bonus into the part of Aura::HandleAuraDummy(). Both of them i see as quite hacky. :( I hope that any of you have any ideas, 'cause i have none left. :unsure:

Link to comment
Share on other sites

i think we are close to finally fix this spell ^^

thanks everyone for your contribution so far...

i hope, we'll have a patch to fix this soon ^^

anyway, i'll do some research to find de exact coefficients that lifebloom takes when it blooms off, but my post above is not far away to the true, belive me :D

Link to comment
Share on other sites

the bloom need to be multiplied per stack like 970x3 with 3 stacks, and that number is used to the get the finla coeficients bases on you spell power...

for example with 1500 spell power should be something like this...

970x3=2910

1500*64.6/100=969

2910+969=3879

so in this case shoulder heal 3879 (no crit) when it blooms...based on 1500 spell power, doesn't matter what talents you have, because the bloom can't be affected with talents chance, just the hot...

this is how lifebloom works, should i post an screen or something to verify what i say?

this calculations are wrong...

this is the correct spell coefficients for lifebloom

[970 +(spell power*64.5/100)]*number of ticks

with 1500 spell power and 3 ticks the bloom should be

1500*64.5/100=969

(970+969)*3=5817 ---------> NO CRIT

thats how works likebloom...when it bloom :D

obs: the hot works fine, the bloom not

edit: last rev, lifebloom still now working

Suggestion: if you ppl can, find a parcial solution for lifebloom, like to heal 5k when it finish it duration or dispelled, cuz heal for 970, and cost 1k of mana :/, druids have everything to lose here

Link to comment
Share on other sites

this calculations are wrong...

this is the correct spell coefficients for lifebloom

[970 +(spell power*64.5/100)]*number of ticks

with 1500 spell power and 3 ticks the bloom should be

1500*64.5/100=969

(970+969)*3=5817 ---------> NO CRIT

thats how works likebloom...when it bloom :D

obs: the hot works fine, the bloom not

edit: last rev, lifebloom still now working

Suggestion: if you ppl can, find a parcial solution for lifebloom, like to heal 5k when it finish it duration or dispelled, cuz heal for 970, and cost 1k of mana :/, druids have everything to lose here

up i'm rolling a druid in a blizzlike server on mangos, and we need this spell

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use