StyleProcessor changes

[Yay]

Hello,

I had a bit time to look through it and made changes in the style damage calculation. I made also changes in the proc delve, but that is not my main concern

I wanted to address the following things:

• style damage cap does not exist on Live because style damage is bound to the base damage done (except if you want to mimic the wrong display of style damage)
• Wyrd missed the offset part of the growth (m * x +n instead of m * x) and therefore the formula is missing an offset (that can be pretty big)
• PA, BS and BS II from Critical Strike follow the same mechanism (rate*spec + offset) as the normal styles with the only exception that weapon speed does not matter
• ToA-StyleDamage is calculated on the base damage and NOT the style damage, therefore detaunts do style damage if you have ToA-StyleDamage items equipped (Live behavior)
• currently DOL delves class specific procs as well as default procs for the same style, altho only the class specific is in effect you could work around this by make class specific procs for every class with the same style, but for lines like 'Swords' that doesn't seem sensible
• readability of ExecuteStyle method in general

I know you shouldn't change too much at once, but the changes in two parts of the StyleProcessor.cs shouldn't interfere with each other. Any testing and/or feedback (beside my own testings) would be welcome. If you do calculations yourself be aware that your unstyled damage may be over your unstyled cap damage (with vanilla DOL and whria-DB for example) and therefore the calculation is changed that way (absorbRatio>1). That has nothing to do with my changes however

To make up for the changes in regard to PA, BS, BS II these queries are necessary:

Code: Select all

ALTER TABLE style ADD `GrowthOffset` double;

(if you haven't started the server after the update)

Code: Select all

UPDATE style s SET s.GrowthOffset = 5, s.GrowthRate = 4.66 WHERE s.SpecKeyName = 'Critical Strike' AND s.SpecLevelRequirement = 2; UPDATE style s SET s.GrowthOffset = 45, s.GrowthRate = 6 WHERE s.SpecKeyName = 'Critical Strike' AND s.SpecLevelRequirement = 10; UPDATE style s SET s.GrowthOffset = 75, s.GrowthRate = 9 WHERE s.SpecKeyName = 'Critical Strike' AND s.SpecLevelRequirement = 21;

After this query the changes to your (test) server should be minimal, meaning it is compatible with old assumed growth mechanic. Most notible should be the change with ToA style damage that was wrongly calculated before.

PS.: In Wyrd there is a different growth rate listed for PA,BS,BSII with two-handed weapons, but that was not in DOL before and would be easy to implement if necessary. I did not yet do it, because I need to test some things beforehand - two-handed damage in general.(already addressed)

[Graveen]

Awesome !!! Let's wait for some review/remark about this

[Yay]

Can't wait to continue the class updates in regards to the styles

I also tested behavior of growth with PA, BS, BSII for two handed weapons. (Static) growth rate is just 25% higher in general and the offset is based on the speed (is static till ~5.325 and then grows linear to weapon speed), but did not find a pattern of calculation for the starting point for two-handed weapons of the growthOffset(weaponspeed) function. I know it sounds a bit complicated right now, but it will be clear in the code once I found the pattern
(5.325 as reference point turned out wrong due to weapon DPS scaling, that I admittedly did not expect)

[Yay]

Oh wow ... as it turns out the GrowthOffset(WeaponSpeed) function for two-handed PA,BS BSII is actually a GrowthOffset(WeaponSpeed,WeaponDPS) function that makes these combination the only one where DPS or weapon level respectively matters. Cause I tested the hell out of the normal mechanism (including the "static growth" for 1h weapons) with highly differing DPS (fast swinging weapons are usually low level).

Conclusion for staticGrowth (PA,BS,BSII) with twohanded weapons:

Note: WeaponSPD is the unmodified weapon speed; haste and quickness doesn't seem to have an effect on the damage here

Code: Select all

GrowthOffset = GrowthOffset * 1.25 + (50/33 * WeaponDPS) * (WeaponSPD - 2.1) Growth = GrowthOffset + GrowthRate * Spec * 1.25

It is also the same as

Code: Select all

Growth = GrowthOffset + GrowthRate * Spec Growth = Growth * 1.25 + (50/33 * WeaponDPS) * (WeaponSPD - 2.1)

Don't ask me why they did that, but I think they felt that the mechanism would be too easy otherwise ;D At least everything makes sense now and fits the calculations and can predict damage reliably.

Edit: Missed two things. WeaponSPD starting point is 2.1 for this calculation. Weapon level and weapon DPS are not interchangable for this calculation because weapon DPS has an offset of 1.2 and therefore scales differently *sigh*. It would have been too easy otherwise.

[Yay]

Ok, I implemented the takeaway from testing.

I'm not entirely sure if this is a good way to test if a 2h weapon is used:

Code: Select all

if (living.AttackWeapon.Item_Type == Slot.TWOHAND)

[Velloro]

Interesting discoveries. I've recoded most of the melee formulas tbh. But I've recently been doing more work with PA/BS/BSII trying to figure out the missing pieces of the puzzle. Looks like you are on the right track here, nice work.

[Velloro]

I like some of these changes you've made, I've been struggling with getting these styles correct as well, but I'm using a totally customized melee code right now. Thanks for sharing some of your discoveries.

[Yay]

I found an error. I used the weapon DPS as modifier instead of the effective DPS. I'll fix it asap. Hopefully not more to come

[Yay]

Updated to version 2, the DPS usage should now be correct. That was not particularly time consuming, but I also checked some other cases where this implementation might fail. It should be stable and correct within a variance of -1 to 0 damage due to rounding errors, but I'm ofc glad if someone independent reviews this

I'm not at home till Sunday, so I can't do much in the meantime (especially not program), but I will ofc read the forum, if I got time

@velloro: Did you also check my damage calculation theory? I'm pretty sure that Wyrd was misled. I can replicate most of his findings if I set my weapon spec to 61 and do this calculation for already known values wyrdGrowthRate = (growthOffset + growthRate * 61)/61. But the result is a quite substantial damage difference to Live for every weapon spec other than 61.

@Graveen: Now that I'm pretty confident that I know the damage classification on Live ("Low", "Medium", "High" etc) how should we handle the delve? Should we now delve GrowthOffset + GrowthRate + DamageClassification or GrowthRate + DamageClassification or only the DamageClassification? Or should we even let it be like it is (ignoring Offset)?

[Velloro]

Yay,

Take a look at the formulas used on camelotherald.wikia.com/Melee_Damage. This was work done by someone named Vanesyra and I am currently using a modified version of them. I found his enemy armor formulas to be incorrect. He calculates style damage using a different formula than Wyrd's growth rates. I also think his Growth Factor correlates in 'most' cases to a kind of offset value you've noticed which I believe is somewhat based off of the damage classification.

[Yay]

@Velloro: Yeah, I found that too, but I also found no correlation to the offset and the style-level. It does work (if you use a shifted growthOffset), however it doesn't make sense to use a number to offset the offset if it doesn't generate nice round numbers (and therefore would makes testing easier). However I found some occassions where I considered this approach. Especially the 3 anytime vampiir styles that target a specific body part (and are almost identical when it comes to growth) where the offset is really incremented ... soo with I will look into that again with the new assumed "quantum". Thank you for the reminder.

The BaseDamage * ToA-StyleDamage is the thing I took from this site btw. That one is nice and correct And now when I think of it the DAMAGE_MODIFIER is likely what I used as absorbRatio ... I really got that wrong :/ If that modifier is correctly calculated somewhere in the code I will use that (will look into it later this week, because not much time). Also a bit of a bummer that it was there all along and I did misinterpret it (mainly the DAMAGE_MODIFIER) ... on the other hand it's an approval of my findings (if I now understand it correctly .. gnarf).

The armor formula is correct. That's a thing I knew before tho

Regarding Wyrd: I really benefitted from his work, but he was unfort (slightly) wrong about his formula. He just tested all styles at a specific spec level and that's what you get now, but if you test at another spec level (especially if it's far away from his tested spec) you often get weird values for many styles (with offset of 0 it coincides ofc) and you start questioning yourself ... and then the formula .

[Velloro]

When I implemented those formulas from wikia, I didn't get the right damage compared to pendragon test logs. Once I modified the enemy armor formulas based on a lot of trend analysis and data collection, I got consistently correct values. Odd it works right for you. I may need to revisit that. The style formula on wikia actually uses logged values collected from a packet logger. You can find them on etaew's database as well. I think some styles have special factors as you mentioned that they don't all correlate to the damage classification. I think both sets of formulas probably net similar results, just do so in a different way.

Edit: Now that I think of it, I may have just realized why it didn't work for me originally. My solution still netted proper results though, odd.

[Yay]

If you are referring to the overall damage, you're right. This is not correct currently, because the base damage is not (entirely) correctly calculated. At first I just wanted to do a checkup and update to the styles, but in the end it turned out that I did not even have the foundation to do this and therefore I did what I did . Yeah I will likely also do a contrib in regards to baseDamage, but it is not my first priority. I also did not know in the first place that unstyledCap and baseDamage was incorrect, but I stumbled pretty early over this. It didn't impact my style testing tho, for obvious reason (it's calculated against baseDam/unstyledCap ratio), so I ignored it for now.

I also found that the damage to low level mobs is a bit quirky. More precisely your cap damage is consistently reached on a way higher level on Live. For example: L50 chars vs 20-24 mob let's you do cap damage with 52 Spec on Live, but not always on DOL ... yeah anyway, I will investigate this at a later point

On an unrelated note: I also wanna do some aggro testings when all classes are roughly working as intended. That was something that always annoyed me on Uthgard (where mobs are a challenge actually ... yet another thing that DOL needs). I always had the impression that it's not correct and that applies to DOL in general too.

tl;dr:

1. style mechanic is 1st priority and also the style damage
2. class fixes are the next thing and will take a lot of time I think
3. base melee damage is incorrect and needs fixing too and aggro calculation is also on that agenda (the order is not exactly strict tho, but the priorities are)

[Tolakram]

You are of course making sure to test with a 100 quality weapon at 100 condition, and checking this every time? These tests drove me crazy last time I tried to change it and I gave up, insead adding a few server properties to change the overall damage numbers.

[Velloro]

Actually, if you are taking damage readings on Ywain or Pendragon to compare against, the best option would be to use weapons at 70% condition as the gradual degradation from each swing will otherwise skew your data. You won't be able to correct style damage until base damage is correct. I was able to get within +/-2 points of base damage compared to pendragon before I implemented new style code. Using the formulas for style damage from wikia, I was also able to reverse calculate a comparable Wyrd-style growth rate value which of course varied with spec to validate my implementation. I spent about a month building functional formulas in excel and evaluating logged test data from pendragon to come up with a fully working solution using the formulas on wikia as a base.

http://www.ign.com/boards/threads/melee ... 452406879/
I was able to glean a lot of useful information and testing tips from the posts made by Vanesyra in this thread. I'm sure you've seen it before, but it still has a lot of hidden gems within it.