Lynx3d

Ah Code::Blocks, i totally forgot it's cross platform. I should give it a try myself eventually.

And i just read Netbeans supports C++ too, apparently it's quite a beast, but maybe that's the kind of thing you're looking for as a visual studio replacement.

Hm i can't tell what is causing it, but the played time gets sent quite often indeed...joined a group, accepted some quests and it showed up like 3-4 times, and a few more times during some dungeons we did.

Hm the only other "real" IDE that comes to my mind is KDevelop.

I also know a couple of people using VIM (with GUI), it can be "pimped" to something similar to an IDE. But I've always been to lazy to really give it a try.

For code browsing i personally use doxygen generated html docu with all extract options turned on, and for editing just SciTE, and since for most OSS projects you can't do much more than telling your IDE to launch make/cmake/scons when it comes to compiling (unless you want to maintain your own project files), it's no big difference to launching it in a terminal really...

If i didn't completely screw the Layer hierarchy in my head, then MAC address is used in the Ethernet layer, NOT the whole internet.

The MAC your server can query via ARP only helps it to determine the physical device that it has to send the packet to so it eventually gets forwarded to the actual recipent. Hence your server will generally not be able to determine the MAC of a player, or HIS router.

As said, you'd basically ban your own router and hence take the server offline...

I do agree that the values mentioned in the first post seem off, though i think the whole dodge calculation is not correct (anymore?).

Looking at wowwiki/elitristjerks, dodge from agility "suffers" diminishing returns, while MaNGOS just adds base doge and undiminished dodge from agility, i can't see where the diminishing formula is applied...

Same for dodge from defense rating btw, see Player::UpdateDodgePercentage()

Does anyone know if the client calculates those chances itself from the base stats and talents maybe?

I think so, according to UDB wiki rank=0 are "normal" mobs, they pretty much define the "normal" damage, i.e. multiplier=1.

-edit-

i should refresh pages i opened a while ago in the background ^^

Looking at the proposed check i'd say that normally the client prevents you from applying the scroll to an unsuitable item class, but if you use cheats you can tell the server to apply it to any kind of equipment, so it needs to check if the client is actually giving a valid target item.

However, wouldn't this already have affected all kind of enchanting items like spell thread, armor kits, arcanums and whatnot? Unofrtunately, i can't read that russian bug report...

This is not really the place to troubleshoot your programming tools...

I'd suggest to read the help for git-apply...for the history and flavours of "patch" ask wikipedia or google...

Hm unfortunately i don't have too many value references there.

If i substracted the demo shout correctly, Maexxna (heroic) should have 19556-26837 damage range.

using the reported -764 damage from -131.2 AP (0/5 improved demo shout vs. 4/5 improved demo shout), and 2.0s attack time:

(764/2) / (131.2/14) means AP modifying effects are 40.76 times stronger than on normal creatures.

I don't know if "heavy snowfall" uses such fractional numbers.

If we assume a round 40 as multiplier, she would have mindmg = 488.9, maxdmg = 670.9, attackpower = 573, dmg_multiplier = 40

For the Azure Mage Slayer (heroic violet hold) i get a dmg_multiplier of merely 1.8, but they seem to be weak and randomly spawned trash, hardly a typical heroic creature.

Another >thread< with number for Uvuros (level 70 elite quest mob) give a dmg_multiplier of 9.0, again much more than i expected from a mob for a 4-man group quest.

The Lurker Below seem to have some special behaviour because the difference between mindmg and maxdmg changes with AP reduction, while on all other numbers so far it stays constant...inconclusive for now.

Finally the posted Aether Ray numbers there again give an expected dmg_multiplier of one, i.e. -1DPS for each -14AP.

Hm i'm not sure what exactly you meant by "it transforms to the actual DPS within the game itself".

Basically i wanted to point out that you must not mix absolute damage values with DPS values in calculations.

mindmg and maxdmg in database are absolute values (per swing), while AP is DPS*14 (an average per time interval). If you just add an absolute value and a DPS value together, you won't ever get correct results.

In your last version, the effectiveness of attack power buffs/debuffs depend on the attack speed.

Slow hitting mobs get a smaller percentual reduction in overall damage than faster hitting ones.

Say a mob hitting with 100 damage every second should get a 15 DPS reduction from demo shout, so it now hits you with 85 every second, that's 15% less. So far okay.

Now another mob hitting with 200 damage every two seconds only gets a 7.5 DPS reduction, because the calculation reduced per swing values from 200 to 185 and continues to hit every two seconds. But it should reduce damage from 200 to 170 to give the same 15 DPS reduction.

About mindmg and maxdmg in the database, i think i found a way to express what i mean in code.

Without any buffs/debuffs, the mob will hit with mindmg to maxdmg per swing, independent of AP. This way, AP only defines how much DPS you can remove via debuffs, or how much stronger it becomes from percentual AP buffs, if those exist...

[HIGHLIGHT=diff]diff --git a/src/game/StatSystem.cpp b/src/game/StatSystem.cpp

index 2e512c3..f215555 100644

--- a/src/game/StatSystem.cpp

+++ b/src/game/StatSystem.cpp

@@ -803,7 +803,9 @@ void Creature::UpdateDamagePhysical(WeaponAttackType attType)

UnitMods unitMod = UNIT_MOD_DAMAGE_MAINHAND;

- float base_value = GetModifierValue(unitMod, BASE_VALUE) + GetTotalAttackPowerValue(attType);

+ /* difference in AP between current attack power and base value from DB */

+ float att_pwr_change = GetTotalAttackPowerValue(attType) - GetCreatureInfo()->attackpower;

+ float base_value = GetModifierValue(unitMod, BASE_VALUE) + (att_pwr_change * GetAPMultiplier(attType, false) / 14.0f);

float base_pct = GetModifierValue(unitMod, BASE_PCT);

float total_value = GetModifierValue(unitMod, TOTAL_VALUE);

float total_pct = GetModifierValue(unitMod, TOTAL_PCT);[/HIGHLIGHT]

If you put this in the DB:

mindmg: 422

maxdmg: 586

attackpower: 642

baseattacktime: 2000

I observed hits with 422-581 (what a surprise...), and with demo shout (-411AP), it does 362-525 damage.

Now go check that tankspot link again...

Absolute minimum damage range with a debuff >= 642AP would be 330-494 (minus 91.7 dmg or 45.8 DPS), but i can't test that right now...

I can follow you up to:

With this i would get

- 45.8 DPS from attackpower

- 211 DPS from mindmg

- 293 DPS from maxdmg

But those values:

mindmg before any modifiers (armor etc) = 256.8

maxdmg before any modifiers (armor etc) = 338.8

...are still DPS values, damage per second, not per actual swing.

Nearly the same as threads starter, but attackspeed dropped out. I don't see a reason for it being there..

For exactly that reason, converting DPS back to damage per swing, so slower hitting mobs (with accordingly higher min/max dmg but same overall DPS) get their damage per swing reduced more from demoralizing shout, to net the same percentual reduction.

That's also why your damage above comes out too low. Not by 2.0 because you effectively had AP contributing twice, but you noted later you had to substract it in database:

Then the gathered data could be used, but after mindmg, maxdmg have been reduced by the amount of dmg AP gives to them..

That was the point of the first proposed patch after all, the only difference remaining is that the 45.8 DPS from AP with attack time of 2.0s gives 91.6 damage per swing.

Hence my previous calculation to substract 92 from mindmg and maxdmg in DB, not 46 as you would suggest.

Of course it would be nice if the core would only substract (or add in case enemy gets buffed) the difference from current AP to its base attack_power given in the database, so you really can set your 422dmg/586dmg/642AP/2000ms from the example,

But i'm not sure you can query the base value with existing Unit functions...

MaNGOS 0.14, rev. 8132

UDB 381

SD2 rev. 1203

Damage done by Warrior's Slam ability (spell 1464 and ranks) does not show in combat log.

First i thought Slam does not do anything at all, but it does deal damage, i just have no clue how much, seems rather low though for the 2-h weapons i tried.

Hm what was so wrong with the "old way"?

Dagguh and me are basically arguing that the damage multiplier is all that was needed, and that will stay with the proposed "revert" patch.

I just don't see a need to change the way attack power contributed to damage, it screws damage for all creatures right now and requires recalculations of all values to get back to values reported from official servers, without allowing any new mechanic.

No doubt without the damage multiplier elites and especially bosses had way to much attack power and debuffs had a far too weak effect, but when bosses like Maexxnar get a multiplier of 40, the old damage and attack power values only need to be divided by 40 and it should be fine.

Mobs may still have too high or low attack power, but that's a matter of researching how big the AP contribution really is, it seems the 30% stated on wowwiki is quite a bit over the real percentages, looking at values with different talent buffs indicate the cap is quite a bit below 30% for normal mobs and even bosses.

I took the values from post #20 and got:

damage from AP: 2000/1000 * 642 / 14 = 91.71...

mindmg: 422-92 = 330

maxdmg: 586-92 = 494

attack_power = 642

dmg_multiplier = 1.0

With these values and the patch i get ingame on a Lvl 80 Warrior, 38.54% damage mitigation:

258 - 358 (combat log)

=> 420 - 582 raw

with demoralizing shout (-411 AP):

224 - 325

=> 364 - 529 raw

average reduction of 55, slightly less than expected (~58) but very close to those tankspot values

Fine, then it has only ~18% total damage from AP, still more than most (all?) classes can debuff solo, but that's not the point...the point is, attack power currently scales with complicated factor that is dependant of attack speed and hence needs individual dmg_multiplier calculation for each mob.

Yes, normal mobs do require dmg_multiplier != 1 currently to have blizzlike damage behaviour, and min/maxdmg indeed gets skewed by that.

Let me calculate the example of the Infesting Jormunga again:

Melee Damage 421 - 587

Attack Speed: 2.0s

That's am average DPS of 252.

Say we want 30% of that from AP, that is 75.6 DPS, or 151.2 damage per hit.

So let's substract that from min/max damage, and set the attack power to 75.6*14 = 1058.

You can already see, a ~500 AP debuff would remove about half of the AP bonus of this mob, wich is inline with the mentioned ~16% reduced damage with skilled demo roar.

With the proposed patch here, we would set the DB values to:

mindmg: 270

maxdmg: 436

attack_power: 1058

dmg_multiplier: 1

However with the current core code, we have to adjust the damage multiplier by 2/14, which backfires on our mindmg and maxdmg so we get:

mindmg: 1890

maxdmg: 3052

attack_power: 1058

dmg_multiplier: 0.14285

This is obviously far from intuitive. And yes, i just set these values in the DB and fought some of the mobs, the damage is as expected, and demoralizing shout reduces it as expected.

I find Dagguh's math plausible too, the proof of wowwiki formulas is in Fenier's post of the posted tankspot thread:

The Infesting Jormungar.

If we assume normal mobs have a dmg_multiplier of one, things work out perfectly:

Demoralizing Roar: Base Value of -411 AP

That would be -29.3 dps. In UDB this mob has attack time of 2s, which would translate into ~58.7 damage reduction, and the values listed are indeed 59 lower with Demoralizing Roar.

Unfortunately there's several different "Azure Mage Slayer" entries in UDB, but dmg_multiplier would be between 1.35 and 1.8 for the values listed...

And bosses like Maxxnar would indeed have a multiplier of 40 according to the data, that's quite a bit higher than i expected.

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.

I still don't get why the formula was changed in [7904] in the first place...they did add the damage multiplier, fine, but why did attack power suddenly give one damage per AP and disregard attack speed?

I thought they just changed meaning of the attack power field, but seeing that AP debuffs are now totally overpowered, it seems just wrong now...

From what i can tell, line 9 and 10 of the patch here are equivalent anyway, and 20+21 are pretty much equivalent to what the code was before 7904...so it's a (partial) revert...

So the only change remaining from 7904 is that final min/max damage are multiplied with new damage multiplier...

Selecting characters ordered by honor points gives me the creeps, with SUBSTRING_INDEX on WHERE and ORDER BY clauses, i really don't want to know how much CPU time each query eats...apart from the fact that the query is unreadable

If our little realm had more characters we'd probably have to cache those values in a special table anyway, or get rid of the statistics page...

Also, there's indeed problems with reading data blobs blindly, while writing the converter for our arcemu DB, i've noticed that when you don't set max item durability in the item instances for example, you get indestructible items because it is never reloaded from item_template apparently...

No, 8059 was Force of Nature (another broken summon), though somehow github page doesn't want to update, but you can get the changes (including logs) with git.

Hm does that actually fix discovery for you?

It is now loading the table, but i get errors like

Loading Skill Discovery Table...
ERROR:Spell (ID: 61288) not have have MECHANIC_DISCOVERY (28) value in Mechanic field in spell.dbc and not 100% chance random discovery ability but listed for spellId 57209 (and maybe more) in `skill_discovery_template` table
ERROR:Spell (ID: 61177) not have have MECHANIC_DISCOVERY (28) value in Mechanic field in spell.dbc and not 100% chance random discovery ability but listed for spellId 56944 (and maybe more) in `skill_discovery_template` table
ERROR:Spell (ID: 60893) not have have MECHANIC_DISCOVERY (28) value in Mechanic field in spell.dbc and not 100% chance random discovery ability but listed for spellId 53895 (and maybe more) in `skill_discovery_template` table

And minor inscription research still does nothing.

I'm using MaNGOS 0.14 [8040] with UDB 0.11.5 (381)

I've seen someone post those errors on UDB forums too, but no reply yet.

All believable sources i found said that Steady Shot *does* use normalized weapon damage (weapon_dmg/weapon_speed*2.8). Unmodified does not mean unnormalized apparently.

The Hunter DPS spreadsheet from elitrist jerks also uses this formula...essentially summarized as:

Base_dmg + Ammo_DPS*2.8 + RAP*0.1 + weapon_dmg/weapon_speed*2.8

Sorry but i can't confirm that, my hunter pet is regenerating energy just fine as of [7927] and i'm pretty sure it also did yesterday with [7917].

The only thing that is bugged is that autocast is disabled despite the action bar indicates it is enabled whenever you pet appears.

Just tested using mana potions and life tap with this patch applied to [7894].

No more strange jumping, mana goes up the correct amount and stays there.

No other problems found, but really only killed a few mobs to burn some mana.

Can't believe it was something that simple, i hope this function swapping has no unintended side-effects.

In any case, two thumbs up for finding the problem!

Even though this is not really the topic, our little server (linux) also has vmap options disable because it hangs up way too often. There's already some threads about freezing with vmaps enabled, even with stack traces to see where the server hangs, but i just couldn't find a good hint why it does yet.

Creatures not going in the air would be nice indeed, however i'm not sure how it works on official anyway, i heard most creatures do not even aggro when you're in the air.

Also things like pulling enemies from a place you can't reach straight by foot, you'd need a path finding algorithm, and if you can't reach it at all, the mob probably should evade, all of which is not that easy to implement at all.