Lynx3d

I don't think anyone will debug some code you found who knows where... This code seems to guess the field type, and guesses wrong. Or it just screws up on the file format, you didn't give much information on what it actually does. I'd suggest the same as darkstalker, use mangos' code, it works for extracting all fields with known meaning, and then some...

A wise man said "you don't need to have everything in your head, you just need to know where to look it up" I've never looked into scripting, but i'd say you'd do something like Player->GetSession()->SendNotification(...)

Hm all the discussions across the net about Ignite and Deep Wounds i found explained that the remaining damage get spread over the whole duration of the new DOT that replaces the existing one, just like it has been implemented in [9057]. :huh: Or can anyone present a combat log showing different behaviour? Did it change with some 3.x patch? Spreading over new DoT means that damage can indeed accumulate arbitrarily when you crit often enough in a row, but it's really just delayed damage, the logic behind it is not broken IMHO. Say you can crit 10 times always before the first tick comes, you get a single DoT with the damage from all crits accumulated. But you did not get any DOT damage while building up this massive DOT. Checking the numbers calculated look good to me too, tested with an arms warrior wielding two daggers. However, this way i'm seeing about 50% of my total damage just from deep wounds, and i saw the same from a titan grip fury warrior just yesterday, outclassing other DPS classes by far. This makes me think something else is actually fishy here! :confused: In the old code that got removed in [9057], i see: // 1 tick/sec * 6 sec = 6 ticks int32 deepWoundsDotBasePoints0 = int32(damage / 6); In the new code added, i can't see such a division. Could it be that Deep Wounds is simply doing 6 times too high damage right now?

Well, it does not say "gives you a 100% chance to parry" but rather "increases you chance to parry by 100%". That does not automatically mean that you are invincible in my opinion, if your opponent has more expertise than you have parry (without deterrence, that is), he still should have a chance to hit you...no? However, that would not be a very likely case it seems... About "deflected" showing up in combat log, that one seems a bit more complicated. Apart from spells avoided by Deterrence, it seems "deflect" is a special form of "parry", and all classes that can parry will deflect certain spells rather than parry them. I'm just not sure what the exact criteria is. It seems that typically spells get deflected that: - are classified melee (dmgClass=2) but don't deal physical damage (e.g. Hammer of the Righteous) - are classified melee but have a range other than melee range and have certain non-damaging effects like inebriate, knockback, reduce hit chance...

@zhanhang02: he simply implemented this formula: http://www.wowwiki.com/Formulas:Armor_penetration Implementation looks correct to me, given that wowwiki is correct. But if you're picky this is not really a proper patch (as in something GNU patch etc. would actually eat...)

Removing beginning of a file seems an expensive operation to me...I think you need to realocate the whole file each time with most file systems. To me darkstalker's idea sounds good, have two log files, e.g. log.head and log.tail. You write to log.tail until it grows too large and then just swap files and trunkate new log.tail, then you always have at least LIMIT bytes and at most 2*LIMIT bytes of output.

But you did not insert weapon DPS in your first post, but absolute weapon damage. DPS (avreage damage per second) of the gun you used is (254+472)/(2*2.8) = 129.6 But you inserted 254 and 472...

Hm okay after reading some more, yes the IEEE standard defines five exceptions for floating point operations, but at least on x86 Linux and Windows by default they are not trapped, the CPU recovers and sets appropriate exception flags. Most operations have a defined result anyway (unlike an integer division by zero for example). Each compiler/platform has its own options and built-ins to change this (if any). The behaviour of casting INF to integer is in fact undefined from what i could find out, but it "only" causes the invalid exception (like operations that result in NaN). But the same happens when the float value is simply too large for the integer type. As we now know, x86 hardware chooses the largest magnitude integer... In any case, these are conditions you should check in code IMHO, because depending on the specific case, accepting exceptional values may be desired or not....and at least C99 added function to check if a floating point exception occured, so no need to force trap, emit a signal and possibly invoke expensive exception handling. E.g. enabling trapping might cause the vmap code interrupt the core ever so often, but may be written in a way to handle the occurence of INF and NaN just fine. At least my raytracing code explicitly handled such situations in several places...

A float division by zero is perfectly legal and results in +inf or -inf depending on signs obviously. Only 0.0/0.0 is treated differently and results in NaN (not a number). That still doesn't mean you program throws an exception though, to my knowledge/experience it will produce a quiet NaN that "infests" everything that touches it. Apparently, casting inf to integer results in the smallest/largest representable value, but i don't know what the standard exactly says about this. Kinda hard to google this specific case...and i think it doesn't really matter in this case anyway.

The spec i used was Marksmanship with a few Beast Master talents. And i don't use hunter's mark at all on normal mobs... (was all PvE btw.) But none of the mentioned effects comes anywhere close to a spontanious 75% damage increase... Only thing i could imagine would be some mob going berserk and increasing damage done and taken by a large amount, possibly more than its buff says.

You are aware that the link is about dual-wielding class builds? :rolleyes: No, not really. You may get "dodged" or "parried" but not "missed" in combat log when you are hit capped...

Okay after some recount collecting, the damage is definitely weird. My hunter (lvl 75, ~2.5k RAP, Mark-S Boomstick + Mammoth Cutters) does on average ~1700 per kill shot. That's sometimes not even enough to finish off mobs... However, sometimes it does a LOT more damage, the maximum recorded was 2996 (non-crit!). And no i'm not running around with aspect of the viper most of the time I have no clue where those 75% extra come from, the only thing i'm aware of that can trigger is my Sonic Booster, but that's only a 430AP bonus and triggers frequently... can't think of any talent proc or mob self-debuff that could increase damage that dramatically.

I was trying to point that out in post #6... GetMaxPower(POWER_RAGE) definitely returns 1000, not 100. I just tried again just to be really sure now i'm not telling crap... I'll also repeat that i believe the rage cost for Execute is already taken when calling Spell::EffectDummy. And on a second look, i even think the refund logic here is flawed... "if(lastrage < rage)" does not give any hint about the value of "m_caster->GetPower(POWER_RAGE)-rage" which must not be smaller than "lastrage" due to the talent.

Weird because the formula i posted is >straight from wowwiki< too... And maybe i wasn't clear, i meant to say your calculated Kill Shot max. damage is 1700 too high, because your white damage calculation is wrong, not that your white damage is 1700 or something like that. According to "my" formula the white result is: 472 + (2.8 * 4200/14) = 1312 Note that this is without ammo DPS and scopes, or the 5% ranged bonus from talent. With some +15 DMG scope and +67.5DPS ammo max. white damage should be in total: 1.05 * ( 472 + 15 + 2.8 * (4200/14 + 67.5)) = 1591.8 You can easily verify this calculation in your character screen... I don't want to claim Kill Shot does correct damage, i only know that i have reached higher crits than 6k at level 75 solo already, and will do the math on next occasion.

Hm seriously i went through all code again, and tested ingame, and really think internally 1 rage is 10 power units. My executes never actually take 30 rage, only up to 19. Bonus damage also seems close to non-existent. First hint: "manaCost" of Execute is 150, not 15. Second hint: bonus damage is calculated as: rage_modified * m_spellInfo->DmgMultiplier Execute Rank9 reads: "converting each extra point of rage into 38 additional damage (up to a maximum cost of 30 rage)" But m_spellInfo->DmgMultiplier for spell 47471 is 3.8, not 38. So currently you effectively get at most 3 rage converted to bonus damage. But there's more wrong: It says "extra point of rage", that is, max. 30 rage total minus the cost of Execute itself (15 non-talented) so that is 15 extra points of rage that are multiplied by 38. Furthermore, if i'm not totally wrong, the rage cost of Execute has already been taken when calling Spell::EffectDummy. In other words, in my opinion current code in SpellEffects.cpp, line 1439 onwards should read: // up to max 30 rage cost if(rage > 300 - m_powerCost) rage = 300 - m_powerCost; That's what i already had proposed ages ago in my first Sudden Death patch attempt, and i still think it's valid, only that the 30 rage limit now always applies, SD proc or not.

Hm i had the impression 1 rage gets stored as 10 "energy units", for whatever reason (guess only people dealing with heavy snowfall know...). But that would mean the current limitation for 30 rage on execute is implemented wrong...maybe will try later if execute (without talents/glyphs) currently even works as intended.

IMHO your calculation of weapon damage is wrong, weapon damage is: base_weapon_damage + (speed * Attack Power / 14) So your top-end in the first post is almost 1700 too high...

Wait, hasn't it been nerfed to 1% per five seconds, down from 0.25% per (one) second? 1% per second would be insane... According to Elitist Jerks tick mechanics is unchanged in 3.2 (and i also had the impression it ticks every second right now) so it should be 0.2% per second, despite the tooltip change now mentioning value per five seconds.

oh...indeed. Reading blizzard tooltips can be though, so the "for 12 sec." only refers to the debuff that increases DoT damage, DoT uses formulation "over x sec.". Also the extra DoT damage from the debuff does not count as "damage it did on th target", so it heals always the same amount depending on the initial hit, did i get it right now? Some comments on wowhead confused me quite a bit...

Yea the tooltip even says "When the Haunt spell ends or is dispelled, the soul returns to you, ..." Though i assume, the sooner you dispel it, the less damage it did and the less it will heal. Couldn't test yet if that part is implemented correctly too. It's not clear to me by looking at the commit alone...

The file formats are called M2, WMO and ADT...that's gotta be enough i think

I'm not very familiar with the grid structure, but i had a look at vmaps a while ago. Of course you can't read them in notepad, just like you can't read images or sound files in notepad...it's binary data. They don't have any standardized file format, they're basically just a memory dump from the data sctructures used by the vmaps code, which from what i can tell comes from a free 3d (game-) engine called G3D.

If i may try to quote Vladimir in a gramatically more correct form: Note the words "horrible hack"... This is no solution, it's a workaround. Someone better find out WHY you cannot cast said spells when in Shadow Dance instead of overwriting this form and pretend that everything is cool. Is it blocked by server or already by client? It might be a similar problem as Warrior's Charge enabling taltents that need an invisible aura to be sent to client before you can even use the action button...

Hm still not simple enough? git pull git://github.com/Lynx3d/mangos.git vellums

I really don't know what you guys are doing wrong all the time, the patch applies just fine to [8812] over here... How many mistakes can you do with copy, paste and safe? :confused: