EQEmulator Forums - Proc Chance Code

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Spell Support (https://www.eqemulator.org/forums/forumdisplay.php?f=664)

- - Proc Chance Code (https://www.eqemulator.org/forums/showthread.php?t=26520)

EDIT: Created a new thread for the Proc Chance discussion and moved them into this thread

I had a level 71 bard song directly from the EQLive spell list that was supposed to increase the proc rate for bard songs by only 102%, which to me means it should only be making proc rate slightly more than double what it currently is. But, this song was making bards proc almost every swing, which was extremely overpowered. I had to reduce the proc rate setting down to like 5% to get it under control.

Code:

Jonthan's Mightful Caretaker          BRD/71        1: Increase Attack Speed by 70%

2: Increase All Skills Damage Modifier by 6%

4: Increase ATK by 16 (L71) to 18 (L80)

7: Increase All Skills Minimum Damage Modifier by 204%

8: Increase Proc Modifier by 102%

I can only imagine that instead of multiplying these percentage increases by X amount and then dividing by 100, it is multiplying by X amount and then not dividing at all lol. So instead of evasive increasing avoidance by 50%, it is multiplying it by 50 so you avoid 50X more often, which means you get hit maybe 2% or the time or less. And that is almost exactly what I saw from watching this evasive bug.

Hmm, maybe I can look into the source of it and just add a / 100 to the end of the calculation if I can find it. That may correct many other issues where certain things aren't balanced properly. Though, I imagine AndMetal would probably be better at finding what is going wrong here considering all of his spell and AA work lately. But, if I can find it, I think it should be a simple solution. Of course then I will need to adjust the spell values back to what they were by default to match it up with the new correction.

This may be where the bard song I mentioned is adding the bonus:

Code:

                        case SE_ProcChance:

                        {

#ifdef SPELL_EFFECT_SPAM

                                snprintf(effect_desc, _EDLEN, "Proc Chance: +%+i%%", effect_value);

#endif

                                // handled with bonuses

                                break;

                        }

Here's where it's calculated w/ the bonuses (zone/bonuses.cpp):
around line 857

Code:

                        case SE_ProcChance:

                        {

                                //multiplier is to be compatible with item effects

                                //watching for overflow too

                                effect_value = effect_value<3000? effect_value * 10 : 30000;

                                if(newbon->ProcChance < effect_value)

                                        newbon->ProcChance = effect_value;

                                break;

                        }

Now, as far as ProcBonus, it ends up being calculated in the attack code also:
zone/attack.cpp, around line 3664 (in Mob::GetProcChances)

Code:

        ProcBonus += float(itembonuses.ProcChance + spellbonuses.ProcChance) / 1000.0f;

        

        ProcChance = 0.05f + float(mydex) / 9000.0f; //Base chance, based on dex + static chance to proc

        ProcBonus += (ProcChance * AABonus) / 100; //AA modifier in addition to normal ProcBonus from items & spells, percentage of base chance?

        ProcChance += ProcBonus; //Add the bonuses to the base chance

        mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);

        return ProcChance;

So, if we use Jonthan's Mightful Caretaker as our example, the effect_value is 102, which ends up being 1020. In GetProcChances, we start with 0, then the spell value gets divided to 1.02. When we try the proc in Mob::TryWeaponProc (both with & without augs), also in zone/attack.cpp (around line 3674), we generate a random float between 0 & 1. Since 1.02 is always > anything between 0 & 1, we will proc 100% of the time.

I assume this is supposed to be a multiplier (200% = 2x as likely vs base, etc) instead of a direct mod on the proc chance. We should be able to do something like this:

Code:

        ProcBonus += float(itembonuses.ProcChance + spellbonuses.ProcChance) / 1000.0f;

        

        ProcChance = 0.05f + float(mydex) / 9000.0f;

        ProcBonus += (ProcChance * AABonus) / 100;

        ProcChance *= ProcBonus; //Multiplier instead of flat bonus

        mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);

        return ProcChance;

If someone wants to try this and/or commit to SVN, feel free (I'm having some issues w/ Visual Studio after the change to zone.vcproj).

EDITED By Trevius: Removed stuff related to another thread

Ok, I think I have proc chance worked out so it will actually be more in line with how it should be working to add a percentage:

Code:

        ProcBonus += float(itembonuses.ProcChance + (spellbonuses.ProcChance / 10) + AABonus) / 100.0f;

        

        ProcChance = 0.05f + float(mydex) / 9000.0f;

        ProcBonus += (ProcChance * ProcBonus);

        ProcChance += ProcBonus;

        mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);

        return ProcChance;

Edit: I tried this code and it didn't work lol. Proccing 100%. Back to the drawing board...

After looking at it further, it looks like much of the code for proc chance/bonus is bad throughout attack.cpp. I think most of the math needs to be rewritten in order to calculate everything properly. As it is, I don't think it is working anywhere near the way it should be. I will go through the code line by line and see if I can figure out exactly what is being done and if I can find a way to do it the right way or at least better than it is handled now.

Before I go through and do this, I want to see if people agree that I am correct in assuming the following:

itembonuses.ProcChance = The total of +Combat Effects from all equiped items
(So, 3 items each with 5 Combat effect on them would total 15, so that means this is getting 15 as the total, or is there some other math going on somewhere?)

spellbonuses.ProcChance = Supposed to be a percentage increase to base ProcChance that is added to the total.
(So, 100% spellbonus would effectively double your base ProcChance, which means a 10% proc chance is now 20% +other bonuses)

Base ProcChance = .05 + (Dex / 9000)
(So, 380 dex (cap at level 75 with all AAs) would be 0.092 base ProcChance)

AABonus = Number of points * 5
(So, 1 point is 5, 2 is 10, 3 is 15, 4 is 20 and 5 is 25 - Defined in the AA for WeaponAffinity)

If that is all correct, then the way I think it should work is to do"(itembonuses.ProcChance + (spellbonuses.ProcChance / 10) + AABonus) / 100" to equal the total percentage increase.

So, if we have 25 from the AA (+25%), 35 from Combat Effects on items (+35%), and maybe 50 from spellbonuses (50%), our total is 110%. So, we would increase the base ProcChance by another 110%. To do that, we should only need to do ProcChance * ProcBonus and then add that to ProcChance.

The weird part is that sounds correct to me, but that is what I submitted here and it definitely wasn't right:

Code:

        ProcBonus += float(itembonuses.ProcChance + (spellbonuses.ProcChance / 10) + AABonus) / 100.0f;

        

        ProcChance = 0.05f + float(mydex) / 9000.0f;

        ProcBonus += (ProcChance * ProcBonus);

        ProcChance += ProcBonus;

        mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);

        return ProcChance;

Using the examples I gave above, 380 Dex with 5 points in Weapon Affinity AA, 35 Combat effects from Items and a buff that adds 50% to Proc Chance, our base will be 0.092 and with the 110% (really more like 210%) increase, it would be 0.193. That is like going from procing 1 out of 10 swings (10% of the time) to 1 out of 5 swings (20% of the time).

I think that sounds close to right even though the base ProcChance calculation may be higher than it should be to work properly with this.

Now, I just need to go through the rest of the proc code for augs and items :P

what about proc chance field found on items? arent they supose to increase proc chance of that specific item?

Ya, that is calculated elsewhere. And they can increase or decrease the proc rates. By setting that field to 100, you are basically making the item not add or subtract anything to/from ProcChance. If you set it to 50, it will proc 50% less, and by setting that field to 200, it will proc 200% more.

what is the default proc chance % btw? and what is exact DEX formula for procs?

bwt do Reactive/Defensive procs allready coded into emu? they were introduced into EQ with DoN expansion

ProcChance = (ProcChance * ProcBonus / 100); //Multiplier instead of flat bonus

You can't just multiply it by 102 and expect it to work right.

Quote:

Originally Posted by KLS (Post 158360)

ProcChance = (ProcChance * ProcBonus / 100); //Multiplier instead of flat bonus

You can't just multiply it by 102 and expect it to work right.

You can if you are then dividing by 100. So, it would take the proc chance and make it 102% of what it was before and then add that amount to the proc chance again to be a total of 202% what it previously was. When we are talking about base ProcChance only being around 0.09 max (at level 75 with all stat AAs), adding 0.10 to that will only make it 0.19, which is still less than 20% of 1.

I know but the code posted was just multiplying by 102 in that case there was no / 100. Which was the problem. =p

Shouldn't the "/ 100.0f" be dividing the total bonus by 100 already?

Code:

ProcBonus += float(itembonuses.ProcChance + (spellbonuses.ProcChance / 10) + AABonus) / 100.0f;

So, if you get 35 from items, 102 from the spell bonus, and 25 from AAs, it should be 162, then divide by 100 and ProcBonus should be 1.62 which means that the spell bonus part of that should only be 1.02.

LOL, after looking at it again, I think I see what went wrong. It should have been this instead:

Code:

        ProcBonus += float(itembonuses.ProcChance + (spellbonuses.ProcChance / 10) + AABonus) / 100.0f;

        

        ProcChance = 0.05f + float(mydex) / 9000.0f;

        ProcBonus = (ProcChance * ProcBonus);

        ProcChance += ProcBonus;

        mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);

        return ProcChance;

I had accidentally left the += in here instead of changing it to just = so it will make ProcBonus a percentage of ProcChance to add to ProcChance:

Code:

ProcBonus += (ProcChance * ProcBonus);

By using the +=, anything greater than a 100% ProcBonus would make ProcChance 100%, which is bad! It is supposed to just make it do 100% more damage, or basically the same as multiplying ProcChance by 200%. I will try this out and see how it goes.

Yeah yeah code wasn't in front of me for SE_ProcChance so I didn't see exactly what was going on. The code should work the way you posted.

I tried it again and it still seemed to proc way too often. I am still not sure what exactly is causing the problem. For now, I just set it to divide the bonuses by 1000 instead of 100 and that actually seems pretty good for proc rates... So, maybe something is factoring in that I am unaware of.

Code:

        ProcBonus += float(itembonuses.ProcChance + (spellbonuses.ProcChance / 10) + AABonus) / 1000.0f;

        

        ProcChance = 0.05f + float(mydex) / 9000.0f;

        ProcBonus *= ProcChance;

        ProcChance += ProcBonus;

        mlog(COMBAT__PROCS, "Proc chance %.2f (%.2f from bonuses)", ProcChance, ProcBonus);

        return ProcChance;

The highest spell bonus that I am aware of is from that bard song that adds 102%, and the Weapon Affinity AA can only go to 25. The only thing I am not sure about is the itembonuses for ProcChance.

In mob.cpp

Code:

                                        if(itemtmp->CombatEffects != 0)

                                                itembonuses.ProcChance += itemtmp->CombatEffects;

mob.h

Code:

        //PoP effects:

        sint16   StrikeThrough;          // PoP: Strike Through %

//        sint16   CombatEffects; //AFAIK: Combat Effects == ProcChance

//        sint16   Shielding;     //AFAIK, Shielding == MeleeMitigation

//        sint16   Avoidance;                //AFAIK: Avoidance == AvoidMeleeChance

//        sint16   Accuracy;      //AFAIK: Accuracy == HitChance

Maybe it is getting multiplied somewhere, but on my server I have it capped at 50.

So, doing the math, I think the max possible base percent increase should be + 177% (50 + 102 + 25). And since the max dex on my server is 380 without buffs, and with max buffs it only goes as high as 471, that is only 0.10 (10%) proc rate. So, adding another 177% on top of that should be about 0.28 (28%) proc rate which is slightly more than 1 in 4 hits. With a warrior dual weilding, that would make it almost once per round. Hmm, so maybe the code is working right and just seems too extreme, lol. I think that could quickly be fixed by adjusting the equation for the base proc rate, because that will heavily effect the total with bonuses since they are all multipliers.

Having 5% proc chance before dex is factored seems a bit high to me. Especially when even without AAs on a server with max level 60, you can get to 255 dex which would be about 8% base ProcRate. So, maybe instead of adding 0.05 (5%) in the equation, we could add 0.02(2%) before Dex gets calculated. That would bring a player with 255 dex and no other bonuses up to a 5% proc rate, which sounds about like Live IIRC. Then, once AAs, Combat Effects and Spell Bonuses get factored in, a player with 255 dex would be lucky to break 10%. And even someone with 471 dex on my server couldn't exceed 20% proc rate with every bonus and stat maxed. I know that is still way too high, but only bards could get that high as far as I know. Everyone else would be more in the 10-12% range even with very nice gear, maxed AAs, and buffs.

I will give this a try and see how it seems. Do any other admins have feedback on if proc rates already seem good in the current code or not? I imagine it is hard to tell for sure until you start factoring in alot of bonuses. We could probably set the dex bonus code to be capped or to scale down after it exceeds 255 dex.