Yog-Sothoth

All of them?
I've considered the other way, but preferred this one over it.
I don't see how this is hacky.
We have an array that defines buffs that should provide the bonus over the cap. We check if the player has such buffs, remove them from the initial value. If we still have a value above 125, we cap at that value, and reapply all the bonus from buffs after that. If not, we just reapply the value from the buffs without any further change.
To me it looks clean, simple, and we don't need to change any skillmod bonus, they will work like they should.

One of the things that you've mentioned in the other review was that the defense bonus should appear in the skillbox, this will do that, while keeping the buff value over the cap.

Could you please point out the error of my logic?

Like I mentioned in the other review, It's not me. I'm a perfecionist and I've OCD, I wouldn't submit anything with bad tabbing.
Both my patch and the code has perfect tabbing, after I submit them to fisheye the tabbing gets screwed a bit. I don't know what I could do here.

This was how it was before my change.
I merely added the check to prevent an Array out of bound exception.
I'm not dealing with this behavior on this patch, so it should be fixed by whoever wants to.

I point you to getRandomAttackNumber() method on CreatureAttackMap.h.
That's where the logic for adding a certain attack to the available attack pool is made.

This isn't my code, I just added a check. in case we return -1.
This was forgotten by whoever wrote this code. I haven't changed its logic, just fixed it,

Just so we don't change the skillmod, as you've already pointed in my previous fix.
This one will make sure the skillmod used isn't a problem.

You replied to one of my changes as saying that one of the changes should stay melee_defense.
I don't see how this change doesn't suit that need.

I've also commented on where the buff bonus is removed, so we can added them after the cap.

To be honest, I can't see why this isn't a proper one.
I do exactly as you've asked, by using a array of constants. I just made sure that the name of the skillmod doesn't matter, as long as the buff is in the array.

private_defense is added after the cap, this is to make sure stun is applied BEFORE the hard cap.

Very well, I'll be splitting into several patchs as some of those fixes get properly discussed, like the reduction for Intimidate.

Damn, forgot to add the getAttackChance as a method wrapper for the Creature Attack Map.
I will re-upload it.

I've added a proper and more elegant fix to attack chances for NPCs/Creatures.
Please advise before I proceed to add chances to a few attacks.

Yeah, that will work either way.
I just thought this implementation would be more readable, since we know for how much we are going to reduce.

SkillModManager::BUFF constant might be the problem, not the addSkillMod method itself.

It's certainly not being updated in the skillbox.
I've just tested it with the changes to Stun as provided by this patch.
102 Melee Defense before the stun, and 102 after.
Didn't change even after I closed the window and reconnected.

Force Knockdown and Force Intimidate should always intimidate or knockdown their target if hit..
The way it is, it just have a chance, and will work even under miss.

If possible, could you please provide me your research on states and dots?
It simply doesn't seem right that an attack that didn't even land apply any sort of penalty.

Well, 90% of the info that I came across regarding Intimidate mentioned a 33% reduction.
Others in the forums have also noticed this different behavior.
Regardless those two reductions is really something that I want to get right, because in the case of Stun a reduction isn't even there.

I had Stun tested with the -50 to melee and ranged and it was still showing my SKILLBOX bonus, not accounting for the penalty even though it was there.

In my tests, even melee_defense/ranged_defense isn't showing.
Apparetly it appears to only show skills present in the PERMAMOD and SKILLBOX.

How do we deal with Force Knockdown and Intimidate then?

const uint8 CombatManager::defensiveAcuity[3] =

;

Better?

Don't see how as it follows the format of the previous 2 variables.
The Acc at the end should make it clear this variable stores the accuracy, not CoB.

Isn't this more readable and clear?
The old method was not right regardless of how you interpret it.
Applying to the max damage divisor wasn't how it was.

Are you 100% sure?
Force Knockdown for instance was an instant knockdown as long as it hits.
I honestly cannot see the logic of applying States and DoTs if the attack itself did not hit.