Knowledge of base 8 versus base 10, if you can't go past that then I don't know what to do.
Knowledge of base 8 versus base 10, if you can't go past that then I don't know what to do.
Do you know how IBM PC works? It's binary architecture, hence everything is stored as binary (not octal, where you get that?).It's got a new writer and he's toned it down a little bit, but if you look closely he's calculating the value of haste in an octal numeral system.
They use integer (int) as representation of Haste value:
Example of calculations, they are forcing them as float:Code:Build 53504 Rawr.Base\Stats.cs public enum AdditiveStat : int { ... HasteRating, ... }
Can't see anything wrong there. Haste will be rounded to int, but it's not a big deal, they round up every stat there to int. No trace of this "octal" non-sense you are trying to pull here.Code:Build 53504 Rawr.Retribution\CalculationsRetribution.cs stats.HasteRating += stats.DeathbringerProc / 3f;
Like, dude, are you familiar with software developing at all? Because if you aren't, just call it right now, you will embarrass yourself.
[ i5-2500K @ 4.5 ][ ASRock P67 Extreme4 ][ 8GB Ripjaws DDR3 ][ GTX 560 Ti ][ BenQ XL2420T ][ Crucial M4 128GB ][ SeaSonic X750 ]
[ 100% Retribution Guide ] [ Ret Trinket Ratings ]
???
Octal is an abbreviation of binary in computer systems.
[ i5-2500K @ 4.5 ][ ASRock P67 Extreme4 ][ 8GB Ripjaws DDR3 ][ GTX 560 Ti ][ BenQ XL2420T ][ Crucial M4 128GB ][ SeaSonic X750 ]
[ 100% Retribution Guide ] [ Ret Trinket Ratings ]
Do you know how coding works? You can abbreviate binary sequences with octal for convenience. 000 = 0, 001 = 1, 010 = 2, etc. RAWR is written in C, which uses Octal.
Not sure how you all got into a discussion of Octal vs. Binary... Regardless of what you start in for your own human readable convenience, it has to be translated to binary eventually, because that is what the processor understands. Even if your compiler is smart enough to know that 8 = 100, the machine is not.
Anyway, back to Bryntrol vs. Oathbinder.. The proc does not double dip. RV double dips because RV is function of your damage. RV = (.15)(damage). With the buff, RV = 1.3(RV0), where RV0 = (1.3)(.15)(damage0). Bryntrol's proc is just a flat amount, affected by things that modify spell damage (source Wowhead). The ICC buff only modifies damage, not the things that modify spell damage. So with the buff, proc = (1.3)(proc0), where proc0 = (procDamage)(spellDamageModifiers). /slash
Righteous Vengeance doesn't double-dip though. You can manually calculate it in any WMO parse.
Actually, it's in C# (C Sharp). Which is managed code. It's at a higher level than C++ and C.
This whole octal thing is just completely ridiculous. Considering computers store everything in powers of two, octal binary representations would be in 3 by 3 sets. 010. The smallest representation of memory is a character. Which is 8 bits. 8 bits in binary are 8 values. 0000 0000. The best way to represent a byte is in HEX. The only thing happening in this program is the truncation of the float into an integer. It does not round off anything. I registered just because I'm a software engineer and I just had to post.
Ok so there are a lot of misconceptions here.
In terms of procs per minute, they are based off of base weapon speed and not current weapon speed. I know this for example because feral druids want haste because it gives them more omen of clarity procs, which is a ppm ability, when they have more haste because the percent chance is fixed but haste gives more hits in a certain time frame.
Saying that the bryntroll proc gets more damage increase from the 30% buff is completely wrong. With basic numbers, lets say the proc hits for 4000, close to what you said. The 30% buff would make it hit for 4000*1.3 = 5200. Lets say now that instead of that proc rate, from another weapon you could determine that you got about approximately 2% crit. Lets say a normal white hit hits for 2000 and crits for 4000. The expected value of this white hit, assuming they only had this 2% crit, would be .98*2000 + .02*4000 = 1960 + 80 = 2040. With the 30% buff, this would be 2040*1.3 = 2652. Percentage wise, both the proc and the crit buff gave the same percentage of damage increase. Those 4000 crits will now hit for 5200, and the 4000 procs will hit for 5200. Similarly if you had strength instead of the buff, you're attacks might hit for an extra 200, and this damage will be increased by the 30% buff so its an extra 260 damage. There is no arguing this point, it is just a true fact. Maybe you are referring to the fact that the damage increase will be more significant numerically and not percentage wise after the buff. If a weapon was 100 more dps before it, it would be 130 more dps afterwards. If this same weapon was 1% more dps before it though, it would still be 1% more dps afterwards.
The buff increases every single aspect of dps. What you are saying implies that the proc gaines 30% damage, but that extra stats are not improved at all by the 30% dps. In that case the 30% buff wouldn't be 30% of total damage, because then every stat would not get affected by the buff and you're maybe 1k naked dps would get a 30% increase. Every single ability hits for 30% more, and if you crit more, the value of that crit is increased by the 30%.
Try to stay on topic- The OP's question was answered a while ago, hence the lock.