Some problems with the combat code:

[AudioGarden21]

Here's an updated link to the EpicEmu fix mentioned above.

AC - Dynamic Hit Modification

[Furniture]

I ended up not actually fixing it and giving up.

This is still a major issue and this issue is known among eqemu players, causing them to not care about AC.

Its great that kegz has fixed the issue on his server, but that doesnt help anyone else.

Can anyone please share a working fix so we can all have AC function properly?

[jsr]

Str opposes mitigation, so.. You could run a query to reduce str

Update npc_types set astr = astr - 10 where level = (level you have issues with)

Do that, parse, if damage is still too high then repeat.


Backup tables first . And I'm not sure of implications of negative str

[jsr]

A good way to parse;

1.Copy a mob
2. Set min dmg to 1, max dmg to 20, str to the value you want to test
3. Set attack speed to -99 (fast)
3. Create an item with 999 regen and 9999hp . I use one of these for ac 10-1000 in increments of 10
4. Adjust regen cap in server rules to 999
5. /log on, equip item, spawn mob and attack.
6. #damage mob when you want to end fight.

I do this for mitigation testing, it is pretty fast. Gamparse will give you a breakdown of the # of huts at each dmg interval from 1-20. You can graph this to see where the bell curve is compared to live, and increase/decrease str until it is close to where you want it.

[KLS]

I'd like to revisit this, but I'd also like to start some discussion of what exactly we need to fix and how we're going to go about it.

1) AC doesn't have enough of an effect on actually mitigating damage.

-> Two ways to address this, we can either increase the effect of AC within our current formula or we can come up with a new one.

2) Hit chance has somewhat hard to predict scaling and can be kind of a nightmare to balance.

-> I don't think there's a way to really address this without redoing the existing formula which might be disruptive to servers that have balanced around the old (whacky as it may be) formula.

3) The order of avoid damage and check hit chance has always been swapped from what it is on live.

-> This is just a matter of rewriting a lot of the combat code to swap them.

[jsr]

IMO if the goal is to emulate live for mitigation, there are really two options;

1) Put together test scenarios and methods to perform some controlled parsing on live. This requires significant collaboration and effort to get sufficient data in the right way.

2) Look at AC on existing items, assign an expected PC level range to these items to derive a scaling factor per level, and design the inputs from mob stats (str/offense in existing code) to scale at the same rate.

Happy to clarify if this is unclear.

[Furniture]

The way I see it, this is something that is blatantly not working the way it should be. The way it stands, there is no reason to try to increase a characters AC in game and that is a huge flaw. I understand that established servers have their own makeshift balances around this to make it work, but that still leaves this flaw intact. Maybe theres a way to rewrite this and give older servers a way to keep the old code for their servers?

Also I am not understanding this correctly about the STR. Do you mean that if you lower mobs strength, AC will parse with significant damage reduction in regards to the different armor types that I originally parsed with?

The way I have been doing it as of late is by adding a huge bonus to player AC directly in the code. That seems to be working thus far, but for high end game I'm not sure how it would work out.

Kegz from the sleeper says that he will be releasing his fix sometime. Hopefully he has a good solution

[jsr]

Yes STR is opposed to AC in the calculation. If you reduce mob strength you will see an improvement in mitigation.

Basically; STR + Offsense - AC - Defense = mitigation.

In my opinion, you're exaggerating the extent of this issue when you say things like 'there is no reason to try to increase a characters AC in game and that is a huge flaw'.

[Furniture]

I do admit I did exaggerate a bit, but the parse clearly shows in its current state trivial mitigation between banded and fine plate and to me that is definitely a huge flaw. Perhaps the issue all along was the STR of the mobs being too high, I will test and see how it goes, thanks.

[ChaosSlayerZ]

thats because the difference between banded and fine plate is insignificant in raw numbers - its what like 25-30 extra AC? It is a gain but its about maybe 5% improvement. Thats how EQ always was - stats are almost irrelevant unless you have a ton of them.
Not saying its good system, but thats just how it is.

[Goryani]

Originally Posted by Furniture

Here is some parsing info:

I parsed a few different levels, 1-50 and found identical results.

Heres an example, a lvl 26 max defense character vs a white con lvl 26 warrior mob, on all values i parsed for a while until the data was rarely changing after time, my consistent results leads me to believe I have parsed for a significant amount of time


Ungeared: AC - 323 Mitigation - 11
AVG Hit from mob - 37
Max Hit from mob - 52

Full set of banded: AC - 466 Mitigation - 154
AVG Hit from mob - 25
Max Hit from mob - 52

Full set of fine plate: AC - 537 Mitigation - 225
AVG Hit from mob - 24
Max Hit from mob - 52


As you can see, there was no significant damage mitigation increase from 154 mitigation to 225 mitigation, but there was a significant increase from 11 to 154.

What could be the cause?

Unfortunately, these results are not sufficient to determine if any problem exists.

Due to the way the D20 system works, infinite AC should result in an average damage per hit around the 4th DI interval. No min hit is listed but a mob that hits for 52 max and average of below 32 should have a min hit around 14. That would put DI = 2. The 4th DI would be ~18 damage. Therefore, infinite AC should result in an average hit of 18.

Mitigation is subject to diminishing returns (and not just because of any softcaps). A min hit can't be mitigated any lower. Extra AC has zero effect on min hits at the old AC value. It doesn't seem unreasonable that banded is already well into diminishing returns territory. The test needs to be repeated with leather and silk equivalent. It also needs to be repeated for upgrading more than the 7 slots covered by banded/fine plate.

Originally Posted by Furniture

I do admit I did exaggerate a bit, but the parse clearly shows in its current state trivial mitigation between banded and fine plate and to me that is definitely a huge flaw. Perhaps the issue all along was the STR of the mobs being too high, I will test and see how it goes, thanks.

A 4-5% increase in mitigation is not trivial. It's actually quite large. How many extra swings does it take to kill the fine plate geared toon compared to the banded toon? How much time is that?

[Furniture]

Originally Posted by jsr

Yes STR is opposed to AC in the calculation. If you reduce mob strength you will see an improvement in mitigation.

Basically; STR + Offsense - AC - Defense = mitigation.

In my opinion, you're exaggerating the extent of this issue when you say things like 'there is no reason to try to increase a characters AC in game and that is a huge flaw'.

While this makes sense, when increasing or decreasing a mobs strength by large amounts, I have seen absolutely 0 change in mitigation. (From Mobs). I'm not sure why that was happening as I didnt spend a whole lot of time with it. (just in game changed mobs STR to 1 or 999). It seems to work pretty well for client attacks though

[Furniture]

Originally Posted by Goryani

Due to the way the D20 system works, infinite AC should result in an average damage per hit around the 4th DI interval. No min hit is listed but a mob that hits for 52 max and average of below 32 should have a min hit around 14. That would put DI = 2. The 4th DI would be ~18 damage. Therefore, infinite AC should result in an average hit of 18.

Mitigation is subject to diminishing returns (and not just because of any softcaps). A min hit can't be mitigated any lower. Extra AC has zero effect on min hits at the old AC value. It doesn't seem unreasonable that banded is already well into diminishing returns territory. The test needs to be repeated with leather and silk equivalent. It also needs to be repeated for upgrading more than the 7 slots covered by banded/fine plate.



A 4-5% increase in mitigation is not trivial. It's actually quite large. How many extra swings does it take to kill the fine plate geared toon compared to the banded toon? How much time is that?

While this seems like it would be correct, when you actually add in absurd amounts of AC directly, mitigation is reduced to the first interval 100% of the time.


The way I've dealt with this whole thing which works quite well, is by adding a bonus to the amount of AC. At varying levels of increased AC, there is significant mitigation differences between armor sets.

[jsr]

While this makes sense, when increasing or decreasing a mobs strength by large amounts, I have seen absolutely 0 change in mitigation.

It seems to work pretty well for client attacks though

I'd expect this outcome if you changed an NPC's stats without doing a #repop.

[wtbmacestun]

I have a copy of the code kegz used to fix ac on his server if anyone is interested.

Actually I found it in his github as well. Here you go

https://github.com/epicemu/Server/bl...one/attack.cpp

if(RuleB(Combat, UseIntervalAC)) {			
			//int8 leveldif = ((other->GetLevel()) - (this->GetLevel())); // //AC Damage Reduction Level Diff - Kegz @ EpicEmu.com
			damage = ((max_dmg+eleBane) - (otherac * acdiv/100.0f)); //AC Damage Reduction - Kegz @ EpicEmu.com
		}
		else {
			//float acdiv2 = 0.25;
			//int otherac = other->GetAC();
			//damage = ((max_dmg+eleBane) - (otherac * acdiv2/100.0f));
			damage = ((max_dmg+eleBane) - (otherac * acdiv/100.0f));
		}		

		//check if we're hitting above our max or below it.
		if((min_dmg+eleBane) != 0 && damage < (min_dmg+eleBane)) {
			mlog(COMBAT__DAMAGE, "Damage (%d) is below min (%d). Setting to min.", damage, (min_dmg+eleBane));
		    //damage = (min_dmg+eleBane);
			damage = ((min_dmg+eleBane) - (otherac * acdiv/100.0f));
		}
		if((max_dmg+eleBane) != 0 && damage > (max_dmg+eleBane)) {
			mlog(COMBAT__DAMAGE, "Damage (%d) is above max (%d). Setting to max.", damage, (max_dmg+eleBane));
		    //damage = (max_dmg+eleBane);
			damage = ((max_dmg+eleBane) - (otherac * acdiv/100.0f));
		}