Jump to content

Dagguh

Members
  • Posts

    37
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Posts posted by Dagguh

  1. Hi people.

    I have done a small research based on numbers taken from your posts and the formula from the wiki.

    So I am asking is my calculations correct ?

    From wiki:

    (DPS_from_AttackPower + Base_DPS) * Multiplier

    DPS from AP is AP / 14

    so an NPC with lets say 574 AP has 41 AP DPS

    Now we have ( 41 + Base_DPS) * Multiplier

    NPC has minimum dmg 382 and attack speed of 2010 ( 2.01 seconds).

    So, 382/2.01 = 190 Base DPS (minimum).

    Until here:

    ( 41 + 190 ) * Multiplier

    Let's say creature is a Boss, so let's put Multiplier 40

    now we have ( 41 + 190 ) * 40 which is 231 * 40 = 9240

    now let's say there's a tank with 60% damage reduction,

    that's 9240*0.6 = 5544 damage.

    We start over for the max damage:

    ( 41 + (513/2.01) ) * 40 = ( 41 + 255 ) * 40 = 11840 max damage * 0.6 ( damage reduction ) = 7104 damage.

    So if Maexxna has 382-513 damage, 574 attack power and multiplier 40, we have blizzlike values, am I correct?

    I have a question, if this is the way things are done, what is the problem in correcting the formula in the core ? I have no idea of C/C++ programming and I am curious what stands between MaNGOS and the right formula? Thanks in advance !

    There is no problem in correcting the formula itself. You have used values calculated by me, and as you can see they work perfectly.

    However, we have a huge problem with obtaining the data for DB. There is no effective way to obtain these values for all mobs. You'd have to run around on official with 0 damage reduction get hit many times to probably get all the possible damage values (min-max range) and try that again with a weak AP debuff and a maximum one you can achieve. This is too much hard work, unless we get multiple "workers". The case of Maexxna was quickly solved thanks to the Beast Lore skill. http://www.wowhead.com/?spell=1462

  2. It's unit_class is 0, thus it is not part of the dmg / ap change queries.

    So he'll remain with 192 AP. So a -192 DemoShout will decrease his DMG by 192 => his DPS by 96. Looking at tankspot, on official -414 DemoShout is not enough to bring his AP to zero (in fact 571 is needed) and even stripping him out of his entire 571 * multiplier AP would decrease his DPS by ~ 92. So a skill that is 3 times weaker here than on the official is stronger than the official.

    BTW. Are mobs that do not have any class going to receive it some day? You sadi yourself, that Jormungar is a Warrior, so unit_class should be = 1

    But as of current, if dmg mult would be 36. The maxdmg of the boss would be (683 + 805) * 36 = 53568 on 0 armor target.

    So if you'd have 60% dmg reduction (Pretty much top notch armor would be needed for this)

    You'd still suffer 32k dmg per hit. Reading a bossguide the particular boss should be doing ~5k dmg or less in a plate.

    So with these values, if you can get her to do that ~5k dmg, and have the -ap debuffs working well (Btw, i assume that she should do ~7k dmg or so.. where that 5k is calculated when you have demoralizing shout up, as everyone always have.)

    Then it i's going to right direction.

    Yea that amount of damage would be ridiculous,. So, you are going to fill DB with these pure values, and core forumla should be adjusted so that the output is blizzlike? If so, I'm gonna look into this tonight.

    For a temporary addition to my core revert, if anyone wants to play with AP buffs/debuffs working OK, I am updating my first post with a SQL "solution" which involves subjecting mindmg, maxdmg and attackpower values to minlevel.

  3. I never calculated AP that is > 900.

    BTW. I didn't mean that baseattacktime needs changes, (even thought it might), the caluclated differences are negligible ( < 1%) and might come from precision errors.

    A series of question to Seizer. Please answer them, if you would be so kind:

    You say DB has correct AP values for mobs 1-81 and the rest is derived, do you mean 381 or the upcoming 382?

    Because on 381 e.g. Infesting Jormungar has 192 AP, and you said he should have 642.

    Are you planning to utilize dmg_modifier?

    Are you going to adjust DB data to match current core mob damage formula or do you consider the current formula right?

    Could you give me an example of min/max dmg, ap and multiplier for Maexxna that the next updatepack will use?

  4. I just unweared all my armor, that left me with 0.69% dmg reduction, since the base armor.

    Also the dmg range is basically the same on tankspot & on me, since of that 0.69% reduction and if i would have sitted there for 3 hours i might have gotten the absolute mindmg and absolute maxdmg, i just went there for 1 health bar.

    But

      1.
         571  AP
      2.
         2010 baseattacktime
      3.
         339  mindmg
      4.
         505  maxdmg
      5.
         1    multiplier
    

    Are too far away from the values they should have, eg no need to do "hacks" on db..

    Excuse me, what hacks?

    And how do you know what values should they have? The values you are getting might be already processed. E.g. they already include AP.

  5. Using data from tankspot and according to my calculations, Infesting Jormungar should have:

    [HIGHLIGHT=cpp]571 AP

    2010 baseattacktime

    339 mindmg

    505 maxdmg

    1 multiplier[/HIGHLIGHT]

    The AP contribution here is 16,26984 %

    Apparently the 70:30 proportion is not in power, at least not for 60+/70+/80+ level mobs. Wiki says it is a general distribution, and we all know that on higher levels, things work out a bit differently with mobs.

    @Seizer: Well, tehre are some discrepancies and this is understandable, because results coming from you and tankspot are a bit different, but that IMO is negligible.

    Test Case 1:

    Mob: Infesting Jormungar

    Zone: Storm Peaks

    Mob Type: Normal

    Base Stats:

    Melee Damage 421 - 587 Damage

    I infer that they might have some imprecise data.

  6. The goal is to use the values straight without any hacks in either core, or db.

    This.

    This is everything I am trying to do here.

    And I can't stress it out more: this patch is supposed to work with original, blizzard values in DB and vastly needs DB support.

    You do understand that this has nothing to do with the core? This is db related data, in this case UDB.

    Yes, of course. I was just reffering to Lynx3d, telling him that trying to manipulate with current DB data, will not fix things.

    As it is right now, we would have to fix the dmg_multiplier for normal mobs by multiplying with baseattacktime/(1000*14) so the AP contribution aswell as player's AP debuffs aren't horribly overpowered.

    This is what I was replying to, and you must agree, that it's not the way to do it.

  7. Azure Mage Slayer is a Dungeon Elite and deserves that higher multiplier ;)

    I was a bit surprised by the 40 factor as well, but after thinking about it for a while, you can see how Blizz made their job easier via this multiplier. They don't have to code AP buffs/debuffs differently for different mobs. Thanks to multipliers, they are useful against both trash mobs and bosses and still are not imbalanced. Gj Blizz.

    Yea, that would fix AP contribution, but would also mess up the min-max dmg influence terribly. Especially when now all creatures with unit_class != 0 and ap != 0 havbe theri min-max dmg divided by 7.

  8. Exactly. But it has indirect relevance

    Basic math: (a + b) * m = a*m + b*m

    If anything happens to b (dmg_from_ap), it happens m times harder.

    A player has a -1400 AP Demoralizing Shout.

    Mob A has multiplier = 1 and 1400 AP and attacks once per second => dmg_from_ap = 100

    Players uses DS, mob loses all his dmg_from_ap => DS decreased the total dmg by 100

    Mob B has multiplier = 40 and 1400 AP and attacks once per second => dmg_from_ap = 4000

    Players uses DS, mob loses all his dmg_from_ap => DS decreased the total dmg by 4000

    The same spell, but works with different power on mobs with different multipliers.

    Multipliers are here to make static ap buffs/debuffs work on hard mobs too. Nobody would even bother putting talents into Demoralizing Shout if it has worked 40 times weaker than currently.

  9. Thanks for the link. Their research says that after stripping around 573 AP from boss, you cannot strip more, ergo it has ~ 573 AP. But you are forgetting dmg_multilpier, which is high on Bosses.

    My calculations (corresponding to formula presented on wowwiki):

    32.8 AP reduction difference = 191 damage difference

    574 total AP / 32.8 = 17.5 times a 32.8 AP reduction has to be stacked in order to make Maexxna have 0 AP

    17.5 times AP reduction * 191 damage difference from this AP reduction = 3342.5 DMG coming from AP

    Assuming 2000 (2 sec) baseattacktime

    Before multiplier => 574 AP would give 82 DMG

    multiplier = 3342.5 / 82 ~= 40

    With my patch applied Maexnna should have:

    [HIGHLIGHT=cpp]573 AP

    2000 baseattacktime

    405,5 mindmg

    587,5 maxdmg

    40 multiplier[/HIGHLIGHT]

    And it is not about arguing, it's about finding out the truth.

  10. "Without / 14 and having all mobs AP multiplied by 14 in DB, all players AP debuffs would be effectively 14 times weaker against mobs. It is better to keep formulas blizzlike."

    Why would they be? If mob has 720 AP in db table (For example lvl 83 boss in naxx) And that is / 14 before anything else is done, it would be 51. So when you use demoralizing shout for example, it removes what.. 510 ap when talented?

    No, no, no... 720 AP in db table = 720 AP in core calculations. And that is bonus DPS that is = 51 in that case. -510 AP from Demoralizing Shout would make it 210 AP which makes the bonus DPS 15 instead of 51.

    BTW. If a Naxx boss has only 720 AP, that's just wrong data, it would mean that he has ~ 170 DPS * multiplier. Before my patch it would give him +720 DMG instead of +720/14 DPS adn that may be the cause of wrong data in DB.

    Would the mob be then -459 AP ? :P

    As I said earlier, no, and you cannot have negative AP.

    In player dmg calculation 1 AP = 14 DPS, but after alot of research the case seems not to be the same on mobs.

    It is the same on mobs. Mobs are different from players only thanks to the dmg_muliplier. And it is 14 AP = 1 DPS , not the other way.

    And think if you want to add 1000 dmg to mob by adding attakckpower to it, you would need to add 14 000 attackpower in db table. Doesn't sound very good..

    If you want to add 1000 DPS via pure attackpower then yes, you'd have to add 14 000 AP, and yes, it would be a bad idea. Because you should increase mindmg and maxdmg too..... And that's all we need to do.

  11. Changes in playerdmg was purely cosmetic.

    The /14 is needed, because it affects the way how do AP buffs/debuffs work on mobs. Without / 14 and having all mobs AP multiplied by 14 in DB, all players AP debuffs would be effectively 14 times weaker against mobs. It is better to keep formulas blizzlike.

    Attackspeed is directly relevant when considering DPS and DPS is relevant when considering AP.

  12. Is is really <that> much easier...?

    And more colums > more DB usage (not much but still more)...

    Personaly i think its easy enough to select from the data-blob, if you keep track of the order...

    To simplify the DB to much will only alienate people who join to learn...

    You're wrong. It IS whole lotta easier. It's the hardest thing to convert, decode, operate on, especially for new users.

    Thanks, hunuza

  13. Thx for applying patch :)

    But I think, that need added very important part of patch.

    Arcane Potency must trigger from Clearcasting, but Clearcasting is trigger spell too and in Mangos sources start trigger from trigger spell is forbidden.

    Because we must allow trigger from Clearcasting specify, else with proc_event - Cleacasting do not start trigger Arcane Potency

    This is fix:

    Spell.cpp

    void Spell:: PrepareDataForTriggerSystem()

        {
            switch (m_spellInfo->SpellFamilyName)
            {
    -            case SPELLFAMILY_MAGE:    // Arcane Missles / Blizzard triggers need do it
    -                if (m_spellInfo->SpellFamilyFlags & 0x0000000000200080LL) m_canTrigger = true;
    +            case SPELLFAMILY_MAGE:    // Arcane Missles / Blizzard triggers / Clearcasting trigger need do it
    +                if (m_spellInfo->SpellFamilyFlags & 0x0000000000200080LL || (m_spellInfo->SpellFamilyFlags & 0x0000000200000000LL && m_spellInfo->SpellFamilyFlags2 & 0x00000008LL)) m_canTrigger = true;
                break;
                case SPELLFAMILY_WARLOCK: // For Hellfire Effect / Rain of Fire / Seed of Corruption triggers need do it
                    if (m_spellInfo->SpellFamilyFlags & 0x0000800000000060LL) m_canTrigger = true;
    

    Ps: (m_spellInfo->SpellFamilyFlags & 0x0000000200000000LL && m_spellInfo->SpellFamilyFlags2 & 0x00000008LL) - this is Clearcasting flags, maybe find better way of this check. :)

    It works perfectly now :)

    I'm getting Arcane Potency after my Clearcasts.

    Thank You

    EDIT: Please accept the second fix too.

  14. Still, it sometimes doesn't work Oo

    Tested on Witherbark Trolls:

    http://www.wowhead.com/?npc=2557

    http://www.wowhead.com/?npc=2556

    http://www.wowhead.com/?npc=2555

    Run for assistance and when they die in the process, they still slide and are unlootable afterward.

    Btw. when they DO get assistance, they come back at you, but walking instead of running.

    MaNGOS/0.13.0-DEV (* * Revision 7955 - *) for Win32 (little-endian)
    Using script library: ScriptDev2 (for MaNGOS 7951+) Revision [1120] 2009-06-04 22:51:38 (Win32)
    Using World DB: UDB 0.11.5 (380) for MaNGOS 7894 with SD2 SQL for rev. 1106
    Using creature EventAI: ACID 0.1.0 - Full Release

×
×
  • 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