AR and NR

[Lheann]

I took the bait and filled in some numbers:
AR: 2400
Evades: 1900
AAD: 580
Full def, 1k tests.
Measured hit%: 57.4%
Calculated hit% with your calculator: 75.96%

AR: 2800
Evades: 1900
AAD: 580
Full def, 1k tests.
Measured hit%: 69.0%
Calculated hit% with your calculator: 89.99%

Your Calculated hit% is wrong. You used the calculator incorrectly. Read the directions. You assummed that 0 aggdef was full def. But if you enter -100 like the page says to enter for full def then you will find the calculated value is 60.76% for your first test set. for the second set of data it returns 71.99%.

That is 3.3% error on the first test and 2.9% error on the second test. I suspect that in your rush to disprove Ebag you failed to read the directions on the web page. Thank you for playing, but the calculator is within the +-5% range that is posted.

[Ebag333]

I took the bait and filled in some numbers:
AR: 2400
Evades: 1900
AAD: 580
Full def, 1k tests.
Measured hit%: 57.4%
Calculated hit% with your calculator: 75.96%

AR: 2800
Evades: 1900
AAD: 580
Full def, 1k tests.
Measured hit%: 69.0%
Calculated hit% with your calculator: 89.99%

This is from tests from before the default hit/miss chances got removed, but they're still way off though.

You're doing it wrong.

No, seriously. The calculated hit rate (with my calculator) is 60.76% on the first, and 71.99% on the second.

Just over 3% off on the first test, and just under 3% on the second.

Hint:

Enter the defenders Agg/Def bar setting. Note that this runs from -100 (full defense) to 100 (full aggro), with neutral (50/50) being 0.

(Helps if you don't leave the Agg/Def setting at 0. )

You also don't need to take this personally. I would like to see one of the last great riddles of AO to be solved as well (or modeled with a very small margin of error: <1% for most AR ranges is what I'm hoping for),

Your right. I shouldn't take it personally. Apologies.

I'd love to see a margin of error <1%, but it's simply not practical.

I just find the way you are going about it to be very poor. You could share your test data (AR, evades, AAD remaining), but instead you chose not to share anything and you tell anyone that questions you (me so far ) that you are right until proven wrong.

Maybe I've been misreading you, but I still don't see why.

I'm a why guy. If you present something to me, first question I ask is why. So why I ask why you find the way I'm going about it to be very poor, I still feel like I have not had a good reason.

Perhaps I've been disinclined to share more than I feel I have to, part of that probably stems from the fact that I've spent quite literally months working on this. Part of that is that most folks tend to draw incorrect conclusions from raw data. Part of that probably stems from the fact that FC has been so...not secretive exactly, but less than forthcoming on the way it works, and I really don't want to step on Mean's toes. Part of it is that regardless of how perfect my data is, someone will find one test case and harp on why that one is wrong (even if it doesn't matter for the big picture).

Regardless of all that....check yer PM. If that doesn't make you happy, nothing will.

Those 3 tests that you shared held neither proof that 1 aad = 1 evade, nor that you can extrapolate the numbers. You mix everything together: "if you want to (dis)prove the influence of one particular variable through a test, only vary that variable in the test.". I also don't know if you have done more tests to check this (and I can't know whether you have or not, because you don't share anything out of yourself), but 3 tests of 500 hits is very little to base a theory on.

It's really not.

It's a simple test. Does AAO = Weaponskill? Take a high WS, low AAO toon, see results. Swap the two. Does the results change? No? Okay, they're the same.

While it'd be ideal to keep every variable the same, that's simply not possible. There's no way you can (reasonably) setup a toon to have 1k WS, 500 AAO, and then swap that same toon to have 500 WS and 1k AAO. It's not really feasible.

[Josephina]

Outsite of a former Game Director telling us that 1 AAD = 1 Evade. Hmm.. Given the authority of the person that published that information I suspect it is correct.

It wasn't really published, it was a quick reply to a quick question on some convention. Game director's are also not all-knowing about their game (ask Means) and it is not impossible for Silirrion to be wrong about something.

That equation is simply demonstrated by the math me and Ebag333 discussed in this very thread.

Total Defense Rating = ( (evade skill + buffs + implants + perks + procs + debuffs) * aggdef bar mod ) + ( AAD + AAD Buffs + AAD debuffs )

This is not Ebag's total defence, it is actually 1 of 2 points I was disagreeing over with Ebag and for which I was pressing him to know on what he based his total defence on. The base assumption of Ebag is his "diff_ar = ar/(ar+def)"; with def= (evade skill + buffs + implants + perks + procs + debuffs+ AAD + AAD Buffs + AAD debuffs). He treats evades and aad equally when it comes to the agg/def slider.

Seems so far Ebag and I are track with how Evades and AAD work.

Unless I missed something again, it looks to me like you are actually in disagreement with Ebag as well.

(Helps if you don't leave the Agg/Def setting at 0. )

And it does, silly mistake of me, sorry :P

Regardless of all that....check yer PM. If that doesn't make you happy, nothing will.

It does, tyvm

[Ebag333]

It wasn't really published, it was a quick reply to a quick question on some convention. Game director's are also not all-knowing about their game (ask Means) and it is not impossible for Silirrion to be wrong about something.

And it's not impossible for you to be saying it's the wrong game director.

(It was Belith, not Sil.)

I would trust Belith far more than Sil. For one, Belith climbed the ranks and actually worked on the game, Sil went straight from a community type person to GD. So Belith had his hands dirty, so to speak, in the engine, and is far more likely to be able to speak with certainty on something than other GD's would be.

This is not Ebag's total defence, it is actually 1 of 2 points I was disagreeing over with Ebag and for which I was pressing him to know on what he based his total defence on. The base assumption of Ebag is his "diff_ar = ar/(ar+def)"; with def= (evade skill + buffs + implants + perks + procs + debuffs+ AAD + AAD Buffs + AAD debuffs). He treats evades and aad equally when it comes to the agg/def slider.

Ahh....but it has to else my calculator would be off.

While my calculator is not as accurate at full aggro as it is full def, it's still right around that 5% margin of error. If I had more data points for full aggro, I may be able to refine the equation that adjusts for the agg/def bar further. Right now it's on the rough side. (My nano calculator is more evenly accurate, I believe, and the equation is slightly different. Comparing the nano and weapon calc equations, it's quite surprising at how close they are to each other. It's almost like FC took the same equation and simplified it for nanos......)

Anyway, the AAD that I tested with is fairly varied, ranging from 0 to over 1100. The test cases all fall in line with each other (well, technically "in curve" with each other as it's not linear...but....), if that wasn't the case than the tests with higher AAD (over 30% of the total def rating) would stick out like a sore thumb when compared to the tests with 0 AAD. They don't.

And it does, silly mistake of me, sorry :P

So I guess I'm still waiting on you to show me which scenarios my calculator is incorrect on.

[mr_road]

Ebag,

any chance you could plot up the following based on your results ?

on the y axis: difference between observed hit rate and calculated hit rate

on the x axis: percentage of AAD of total def rating ie. AAD / (evade skill + AAD)

could you do that for full agg and full def data ? including threeze's full def data may help as well.


if there is a big enough range of AAD % of total def rating, those plots should indicate whether or not the assumption that 1 evade = 1 AAD is correct.

[Ebag333]

Ebag,

any chance you could plot up the following based on your results ?

on the y axis: difference between observed hit rate and calculated hit rate

on the x axis: percentage of AAD of total def rating ie. AAD / (evade skill + AAD)

could you do that for full agg and full def data ? including threeze's full def data may help as well.


if there is a big enough range of AAD % of total def rating, those plots should indicate whether or not the assumption that 1 evade = 1 AAD is correct.

No.

But what I can do is chart it out, and if you wanted to graph it you could.

http://pvp.aodb.us/ARDEF/display_aadtest.php


IF AAD had a bigger effect at full aggro than full def (or vice versa) you should see a trend of larger inaccuracies as the AAD amount increases. But you don't. The inaccuracies all stay right around 5% (with the exception of two tests), and are pretty randomly scattered.

There is a trend for full aggro that the middle range of Diff AR % tends to be positive errors (in other words I'm calculating too low) while the bottom and upper ends tend to be negative errors (in other words I'm calculating too high) which tells me that my curve is slightly off (it's not flat enough). But that's a minor thing, it just means I need to adjust my agg/def formula. The difference between actual and calculated is still small.

[Mereditche]

Nice work. Gz on finding the formula.

Looks solid to me.

[Lheann]

Unless I missed something again, it looks to me like you are actually in disagreement with Ebag as well.

Actually if you read our exchange in the thread I asked what formula he was using for total defense. And we and him have a few post were we hash it back and forth over the formula and in at least 2 of the post we have the formula I posted to you.

So I fail to see how your statement that he used straight math in which all was equal. I would argue his test cases at full def are such that they all appear equal but the formula is still valid at at somepoint the aggdef bar mod is 1.0.

@Ebag: On the the issue with fullagg on the bar I think I may have an idea. It is theroy that 87.5% (0 to 100 scale) of the aggdef bar is neutral. It has no speed mods and the evade mod factor is the same at 100% (0 to 100 scale). This has been supported over the years by the belief and practice that a 1/1 weapon at level 1 allows you to go 87.5 straight up and from there higher inits let you lower the aggdef bar more towards fulldef side. My testing suggest this is the case as well. If the evade skill modifer value stops prior to fullagg that might be why your error rate goes up on that end of the scale. I suspect you continue to modify evades for aggdef all the way to fulldef.

[Ebag333]

Actually if you read our exchange in the thread I asked what formula he was using for total defense. And we and him have a few post were we hash it back and forth over the formula and in at least 2 of the post we have the formula I posted to you.

Josephina is right though, I do treat evades = AAD, which the formula you posted above does not.

So I fail to see how your statement that he used straight math in which all was equal. I would argue his test cases at full def are such that they all appear equal but the formula is still valid at at somepoint the aggdef bar mod is 1.0.

But not all of my test cases are at full def. I have a decent number away from that, which is how I was able to calculate the formula for how the agg/def bar effects it.

@Ebag: On the the issue with fullagg on the bar I think I may have an idea. It is theroy that 87.5% (0 to 100 scale) of the aggdef bar is neutral. It has no speed mods and the evade mod factor is the same at 100% (0 to 100 scale). This has been supported over the years by the belief and practice that a 1/1 weapon at level 1 allows you to go 87.5 straight up and from there higher inits let you lower the aggdef bar more towards fulldef side. My testing suggest this is the case as well. If the evade skill modifer value stops prior to fullagg that might be why your error rate goes up on that end of the scale. I suspect you continue to modify evades for aggdef all the way to fulldef.

I think you're confusing some things here.

First off, the agg/def bar runs from -100 to 100. 0 is dead center, not 87.5%.

I haven't replicated or tested the speed formula's, so I won't attest or speak on that.

I can say that the agg/def bar has a progressively larger effect the further over you go. So going from -100 to -50 isn't as big an effect as going from 50 to 100. When you plot the points on a graph, this is readily apparent.

That's the other thing, plotting these out would visually show if AAD had a different effect than evades. Because my test cases run from 0% to more than 30% (for how much AAD to evades you have), if AAD had a different effect than evades for a given agg/def number, the spread of plotted points would be very large. They aren't.


Inits/speed are handled completely differently than aad/evades, so it's not applicable to apply one to the other. For one, the way speed has been handled has been adjusted several times, the hit/miss formula has not as far as we know (except for the base chance change).

Init's are weighted very heavily to allow you to be quick at full def. I suspect that with the crazy strength of some nanos (IE: UBT) FC found that it simply wasn't fun if you were attacking once every 5 minutes.

Heck, I can instacast nearly all my nanos on full def while UBT'd, which attests to how easy it is to get silly high inits. The same isn't true for evades. I can't have an evade debuff on me and still evade 100% of hits.

It's not even apples and oranges here. Maybe fruits and veggies......

[Lheann]

Josephina is right though, I do treat evades = AAD, which the formula you posted above does not.

I think you're confusing some things here.

First off, the agg/def bar runs from -100 to 100. 0 is dead center, not 87.5%.

I haven't replicated or tested the speed formula's, so I won't attest or speak on that.

But I do agree Evades = AAD. The aggdef bar is a modifier that is only applied to evades. It is because of this modifier that evades appear to not equal AAD.

I was not saying that init and evades worked the same. I was indicating that inits/speed is effected across the entire aggdef bar and that my testing and other testing documented in the forums seemed to indicate that at 87.5% (0 to 100 scale) and above evades seems to be the same. Chronita had speculated back in the day that the aggdef bar only changed evade modifiers every 12.5% and that >=87.5 all had the same modifier. On of the reason early skins have dividers on the 12.5% stops

I am aware that your 0 (-100 to +100 scale) would be the same as 50% (0 to 100 scale) and that 87.5% is not the middle. Your statement that the effect is not linear actually supports the idea that the effect of the aggdef bar on evades changes the closer you get to fullagg.

I keep refering to the aggdef bar as a 0 to 100% scale and you are refering to it at a -100 to 100 scale. Given those two different scales I will map my understanding of the two
-100 = 0%
-50 = 25%
0 = 50%
50 = 75%
100 = 100%

I however do not subscribe to the idea that 50% (0) is the balance point were the aggdef modifier = 1.0. I beleive that >= 37.5% to < 50% is the range where you get 1.0 aggdef modifer. Given that I would accept that -1 to -25 on your scale is the point were modifer for aggdef is 1.0.

I use the 0 to 100 scale as it fits nicely with the break point table system FC uses for so much of their data look ups (the resource database for items is basicly large break point tables). A -100 to 100 scale would indicate you are trying to assign distinct values to a position on the scale, I could be wrong. The very essence of the break point tables FC uses for so much of the data is based on having varying scales along the whole scale. Also they all seems to use a >=0 to some positive value as the break index. Thus 0 to 10 can be drasiticly difference for each point pasted in. Where 11 to 50 can be a less drastic change as the range is wider and the per point difference is less.

Basicaly each of these look ups can have completely different scales associated with them. Further the scale of each does not have to be linear or mathmatical possible over the whole of the aggdef bar range. It only needs be mathmaticly possible between the two bounds of the look up.

After all that I still think your calc is very good. It seems to mirror game results within +- 5% as you advertise and I am thankful for it. I do know the endless hours of data collection and spread sheet horror you went through as I have done some (haha) of this as well.

I do think that the game math is not overly complicated for performance reasons and after looking at the code base for the Open Source Cell MMO server engine I suspect that much of the magic of AO is simple break point tables. Further I suspect that all the break point indexes are designed to be >= 0 values to simplify the interface further.

[Ebag333]

But I do agree Evades = AAD. The aggdef bar is a modifier that is only applied to evades. It is because of this modifier that evades appear to not equal AAD.

Um, that's a contradictory statement (in a sense). If Evades = AAD, then the Agg/Def bar modifier applies equally to both. If it DOESN'T apply equally to both, then Evades != AAD (except at one very specific Agg/Def bar setting).

My calculator assumes that evades = AAD, and the agg/def bar applies equally to both. Why?

1. Because a Game Director publically stated it.
2. Because the formula would be much more complex if this wasn't true.
3. Because my calculator is equally (in)accurate across the range, regardless of the percentage of AAD you have to evades.
4. Because I have a freaking list, darnit!

I was not saying that init and evades worked the same. I was indicating that inits/speed is effected across the entire aggdef bar and that my testing and other testing documented in the forums seemed to indicate that at 87.5% (0 to 100 scale) and above evades seems to be the same. Chronita had speculated back in the day that the aggdef bar only changed evade modifiers every 12.5% and that >=87.5 all had the same modifier. On of the reason early skins have dividers on the 12.5% stops

The problem is that we're dealing with random chance here. Even a test of 5,000 attacks could be off by a significant amount. And (as we've seen from mine and other tests) even those large tests will vary slightly.

If you're adjusting the Agg/Def bar by 12.5%, that's not a whole heck of a lot. As an example, when AR = Def (50% Diff AR %) and at full def (-100), you're looking at a land rate of 63.07%. Bump that up a bit to -90, and you have 64.64%. Go to -80 and you get 66.22%. Heck, bump it all the way to -50 and you still only get 70.95%.

(Yes, those numbers were generated from my calculator.)

Even by adjusting the Agg/Def bar by a quarter of it's length, you're only looking at only an 8% difference in land rate. If you're dealing with a 5% margin of error, it will be very difficult to see any difference that can't be written off as a margin of error.

As a general rule, for specific scenario testing, any result I get that's is that close I write off as inconclusive. It's simple too close to tell.

It's possible that the actually in-game calculator uses break points, but I highly doubt it. And it really doesn't matter for a couple of reasons.

For one, even if it's used, the results will be well within the margin of error for my calculator. So lets say that for a particular case, -100 to -76 will give you a land rate of 50%. -75 to -50 gives a land rate of 53%. And so on. Now lets say that for -100 to -50 my calculator gives you a curve ranging from 50% to 53%. Even though only two points in that curve will actually be accurate, is being off by 1.5% (or less) really that big of a deal?

For another, due to the fact that we're dealing with percentages here, you will never get exactly the land rate that it would be. So you will always have a margin of error.

I am aware that your 0 (-100 to +100 scale) would be the same as 50% (0 to 100 scale) and that 87.5% is not the middle. Your statement that the effect is not linear actually supports the idea that the effect of the aggdef bar on evades changes the closer you get to fullagg.

Okay.

I misread what you were saying. Thanks for clarifying.

I however do not subscribe to the idea that 50% (0) is the balance point were the aggdef modifier = 1.0. I beleive that >= 37.5% to < 50% is the range where you get 1.0 aggdef modifer. Given that I would accept that -1 to -25 on your scale is the point were modifer for aggdef is 1.0.

There is no "balance point" per say. It's a formula. Any balance points we assign are purely arbitrary and are only meaningful to us. The formula doesn't care what point the land rate becomes 100%, or at what point it's 50%, and so on.

I use the 0 to 100 scale as it fits nicely with the break point table system FC uses for so much of their data look ups (the resource database for items is basicly large break point tables). A -100 to 100 scale would indicate you are trying to assign distinct values to a position on the scale, I could be wrong. The very essence of the break point tables FC uses for so much of the data is based on having varying scales along the whole scale. Also they all seems to use a >=0 to some positive value as the break index. Thus 0 to 10 can be drasiticly difference for each point pasted in. Where 11 to 50 can be a less drastic change as the range is wider and the per point difference is less.

Basicaly each of these look ups can have completely different scales associated with them. Further the scale of each does not have to be linear or mathmatical possible over the whole of the aggdef bar range. It only needs be mathmaticly possible between the two bounds of the look up.

It really doesn't matter if you use -100 to 100, 0 to 100, or 5837.27198 to 927271817.282872.

Because of the way that the formula's work, you can achieve the same results with any of those ranges, just your formula changes slightly. You might multiply the Agg/Def number by .0001, or by 1000, or by 1023723, but your end result is essentially the same.

Many different numbers can create the same curve, if the formula is adjusted properly.

I choose -100 to 100 for a couple reasons:

1. In figuring out the formula, -100 to 100 gave me very simple equations that fit together nicely. 0 to 100 was a tad more complex, not so much so that I'd call it improbable but it didn't quite work as simply.
2. A little birdie on TL may have made some sort of mention about -100 to 100.....

Again, it's rather arbitrary and it doesn't matter what you use, you just need to make sure the formulas work with whatever range you are using.

It seems to mirror game results within +- 5% as you advertise

And that's really the ultimate pass/fail test.

I do think that the game math is not overly complicated for performance reasons and after looking at the code base for the Open Source Cell MMO server engine I suspect that much of the magic of AO is simple break point tables. Further I suspect that all the break point indexes are designed to be >= 0 values to simplify the interface further.

I disagree.

For one, we know that there are actual formulas used. For example, the 3% base chance. If that didn't effect all AR ranges, it wouldn't have been a major change, and (likely) would not have been in the change log. Unless they went through and subtracted the 3% base chance from each row. Which would be....tedious...

Two, I haven't seen any sort of a break point. IF break points are used, then they are so close together that a formula might as well have been used.

Three, in the cases that we see break points used, there's still a formula being done. Take AR effecting damage, or item QL extrapolation. But in both of those instances, it's a linear equation, not a curve. It's way more complex to use break points in a curve than to use them in a linear equation (not impossible, mind you, simply more difficult). And if you graph it out, it is very clearly a curve.

[Ebag333]

It does, tyvm

So. Any thoughts yet on that? Or have you given up?

[Lheann]

.. Bunch of stuff ebag wrote ...

Well having inside information on the aggdef bar is for sure a plus to your case.
Yes a GD said evades = AAD. But he did not say aggdef bar effects both.
I really do like the calculator.
You have a nice list.

As for the aggdef not effecting AAD. This is why I feel that way. Way back before SL was in beta they addressed and fixed evades as they did not work at all. Old players remember 1000 evades and 100 evades had the same result at all aggdef ranges. The time frame was 12.6-13.0 series of love and hate. However prior to this fix we had grid armor come to us. I was playing on test at the time and when it came out and actually worked, we asked if AAD (listed as a stat) was greater than evades (was first realy use of it as a stat outside ring of luck). The answer from the devs was AAD made GA work as designed even with evades being broken. That the furture planned evades fix would not break GA because of this and it would actually improve the performace of GA. The small amount of evades on it was required to make the math work (something about getting 0 as a total if not there) and that AAD was added in after all the other equations had been processed.

Take it or leave it. But that is the basis for my understanding.

As for break point tables not being able to produce a curve. One of our simulations uses the GE break point tables from GE's jet turbine validation system to reproduce the engine operations and most importantly (for us) the thrust curve. When plotted we get a very nice curve. We also get nice curves, when plotted, of all the engine performance data. Break point tables always require the extrapolation math to work between the break points and there is no "math free" method of doing break points. But they are very handy in reducing server load as you use extrapolation math for one or two parameters vice doing all the complicated math every time. If a series of 20 or so tables can reproduce jet turbine performance data I suspect something as simple as a MMO hit/miss math can be done as well and it look like a nice curve. Remember the amount of processing the server does. Look ups and extrapolations are much faster than raw math and a MMO is all about reducing server lag where possible. While your math may be 99% accurate to the math used in game I tink for lag reduction lookup and extrapolation would be faster. There are parts of your math that once computed could be stored as a look up and prcoessed faster that way. Ok as in visually faster no. But as in less than 100ms round trip time processing time it would be faster. We all know how much ping times over 100ms make the game feel so response time for the math would be important.

I beleive that removing the base 3% hit/miss chances was such a large scale change as the hit miss math was probably proofed with the 3% values included and never thought to be tested with those values set to 0. When you take small range for calculating data and expand it to a large range and in the process remove constant values from the equation I am sure they had to go back and take care of divide by zero issues and other math errors that existed sololy because of the change.

[Noddle22]

|X----------------------------------|
X = Full Def


|----------------------------------O|
O = Full Agg

X = Better than O

Simple graphical math really.

[Lheann]

|X----------------------------------|
X = Full Def


|----------------------------------O|
O = Full Agg

X = Better than O

Simple graphical math really.

Dang that was it all along. Made me laugh.
Sometimes the simple stuff is what makes this game great.
The enforcer approach to programming. Big hammer and me bash. It work now.

[Ebag333]

Yes a GD said evades = AAD. But he did not say aggdef bar effects both.

Um no, he didn't. But the statement doesn't make sense otherwise.

Why would you say evades equaled AAD if evades *DIDN'T* equal AAD 199 times out of 200?

If I told you to guess a number between 1 and 200, and you were wrong 199 times (finally getting it right on the 200th try), would I say you had a perfect record of guessing?

If the equation looked something like this:
Def = Evades + (AAD*aggdefbar)

The only time when evades are equivalent to AAD is when AAD = 1. That's not equivelent, and if I had that equation and told you that evades = AAD, I'd be incorrect. It's the exception that evades = AAD, not the rule.

As for the aggdef not effecting AAD. This is why I feel that way. Way back before SL was in beta they addressed and fixed evades as they did not work at all. Old players remember 1000 evades and 100 evades had the same result at all aggdef ranges. The time frame was 12.6-13.0 series of love and hate. However prior to this fix we had grid armor come to us. I was playing on test at the time and when it came out and actually worked, we asked if AAD (listed as a stat) was greater than evades (was first realy use of it as a stat outside ring of luck). The answer from the devs was AAD made GA work as designed even with evades being broken. That the furture planned evades fix would not break GA because of this and it would actually improve the performace of GA. The small amount of evades on it was required to make the math work (something about getting 0 as a total if not there) and that AAD was added in after all the other equations had been processed.

There's actually still some bugs around this. For example having a 100% crit rate when evades are less than 0.

That being said, that bug doesn't mean that evades != AAD. As an example, lets say we have the following equations....

total_evades = evade_skill + armor_evades + evade_bufffs + evade_debuffs
total_AAD = AAD_skill + armor_AAD + AAD_bufffs + AAD_debuffs

def = (total_evades + total_AAD)*Agg_Def_Modifier

Okay, so now lets assume that there's a bug with the first equation that it always equals 100. Maybe some dev misspelled the variables for everything except evade_skill. Maybe there was a change made that broke it. Who knows, but there's some bug causing it.

So now our final equation looks like:
def = (100 + total_AAD)*Agg_Def_Modifier

ZOMG! Agg_Def_Modifer only effects AAD!

Umm....no. There's a bug that causes it to only effect AAD, because evades are essentially not counted.

I wasn't playing around that time, so I probably don't know the whole story.

I do know that the agg/def bar MUST have some effect as it does on a toon with 0 AAD. Since 0 AAD or over 1k AAD seems to have the same effect with the Agg/Def bar, I have to conclude that it effects them equally. *shrug*

As for break point tables not being able to produce a curve. One of our simulations uses the GE break point tables from GE's jet turbine validation system to reproduce the engine operations and most importantly (for us) the thrust curve. When plotted we get a very nice curve. We also get nice curves, when plotted, of all the engine performance data. Break point tables always require the extrapolation math to work between the break points and there is no "math free" method of doing break points. But they are very handy in reducing server load as you use extrapolation math for one or two parameters vice doing all the complicated math every time. If a series of 20 or so tables can reproduce jet turbine performance data I suspect something as simple as a MMO hit/miss math can be done as well and it look like a nice curve. Remember the amount of processing the server does. Look ups and extrapolations are much faster than raw math and a MMO is all about reducing server lag where possible. While your math may be 99% accurate to the math used in game I tink for lag reduction lookup and extrapolation would be faster. There are parts of your math that once computed could be stored as a look up and prcoessed faster that way. Ok as in visually faster no. But as in less than 100ms round trip time processing time it would be faster. We all know how much ping times over 100ms make the game feel so response time for the math would be important.

Extrapolation math is relatively expensive when calculating multiple points across multiple ranges.

It can be very quick because it limits your ranges, so it can speed that up. But if you're bridging multiple points, I really don't see how it can be any faster.

Psuedocode:

Z = 4.5*x^y


Break points:

if (x > a && b > x)
{
Z = 4.5*x^1
}
elseif (x > c && d > x)
{
Z = 1.5*x^2
}
elseif (x > e && f > x)
{
Z = 1.5*x^3
}
elseif (x > g && h > x)
{
....etc....
}


The second one is only faster if you need to hit one single case. Now....I don't know your code, so it could be heavily optimized, and your requirements could be very specific.

You can also handle caching of a formula, which would still be more efficient than break points IMHO. (Not that you can't cache a break point....)

|X----------------------------------|
X = Full Def


|----------------------------------O|
O = Full Agg

X = Better than O

Simple graphical math really.

It's funny because it's true!

[Lheann]

Why would you say evades equaled AAD if evades *DIDN'T* equal AAD 199 times out of 200?

In a eqauation where EVADES = 100 and AAD = 200 and AGGDEFMOD = 1.2 based on my concept the formula looks like this:

Defense Rating = ( EVADES * AGGDEFMOD ) + AAD

In this formula EVADES = AAD. EVADES are only modified but the AGGDEFMOD. The fact they are modified does not change the fact that EVADES = AAD. Since at some point on the scale the AGGDEFMOD is 1.0 it could be tested in theroy. If we had the knowledge of where the mod is 1.0 and configured a target with equal evades and AAD and then used the same total as all EVADES and again as all AAD we would have the test data to back it up.

I will now write the equation as I understand you apply it:

Defense Rating = ( EVADES + AAD ) * AGGDEFMOD

Yes in this equation EVADES = AAD. What is not confirmed (unless you got a dev to give it up) is that AGGDEFMOD is applied to AAD as well. You see that is where my interaction with devs on test server says that it does not.

The GD made the statement back in the day as Jobe AAD clusters say it is a % of your evades. Until that statement it was never clear if the cluster description was true or not. It turns out that the description it was not true. If it had been a % value then so much about the math would be different.

Either way there are two equations and only one can be right. That leaves two views of the same basic statement from a GD. Again unless you have a dev that has given up something of late about the math I have to go with what I was told.

Though I think that the difference in toatal defense rating between our two equations i probably going produce results that are inside your +- 5% error rate.

Okay, so now lets assume that there's a bug with the first equation that it always equals 100. Maybe some dev misspelled the variables for everything except evade_skill. Maybe there was a change made that broke it. Who knows, but there's some bug causing it.

... cut some stuff ...

I wasn't playing around that time, so I probably don't know the whole story.

That was basicly the issue back in the day when they fixed evades. It was typo in the equation.

Extrapolation math is relatively expensive when calculating multiple points across multiple ranges.

It can be very quick because it limits your ranges, so it can speed that up. But if you're bridging multiple points, I really don't see how it can be any faster.

... cut the rest ...

Depends on the math you use. Your example is pretty far from how we use them. The basic idea is this.

I have X and it equals 238. The equation X is used in is large and takes a person well over an hour to calculate for one value of X even when X is the only data point being varied. Even the computer is slow at it. So we write an app that does the math offline and saves the data out for every value of X. Lots of data and it takes just over an hour for this one equation to process that data for all values of X. Then we took the data and broke it down into points on the break point tables. That is the not so fun part. The entire time the math was runnig X was the only variable. The extrapolation math then looks like this for processing using the tables:

Look up in Table 1 for X and return LowerBoundIndex LowerBound and UpperBound. This is a fast compare stage. It returns an Index of LowerBound and the two bounding values.

Compute Extrap% at this time.
Extrap% = ( X - LowerBound ) / ( UpperBound - LowerBound )

Now Lookup in Table 2 using LowerBoundIndex that data and the data at LowerBoundIndex + 1. This is LowerResult and UpperResult.

We compute TheResult from LowerBound To UpperBound using Extrap%
TheResult = ( (UpperResult - LowerResult) * Extrap% ) + LowerResult

One divide, one multiple, three subtractions, one addition and two series of compares.

Again we use this in a jet turbine simulation where the thrust component math on a very fast 8 core server at 3.0 ghz takes a little over 2 secounds to return the result. There is no way we could do the math in real time 60hz operations. But the break point tables execute in around 400micro seconds. Huge difference.

I will give that if the base equation has less math operations in it that the break point math then there is no time savings. Of course you have to consider the type of math operations in the base equation as well. But given the complexity of the math used in our application it is much faster. Further the Look ups are optimized for a max of 20 break points so that we know the O of the look ups and can calculate best case and worse case processing times. Knowing that helps determine if the math or the table is faster.

So while that is a simplified example of how the tables work for us it is very accurate. We have complete tables where up to 5 components are variable and it takes the 5 values to get 5 indexes to look at the actually results. But if the simple example above took a computer 2 seconds you can imagine how slow the larger equations can be. Actually have seen current generation Xeon servers takes into the double digit seconds on some of the math. Basicly some of the formulas break down into 200 to 300 lines of math code. Add to that some of it is angular math with sine/cosine/tangent operations and it is just slow.

Again my use of break point tables is problaly not your everyday use of them. The real time savings come when you can simplify huge amounts of math operations into look up tables and the result comes from a simplifed equation that executes with almost no division and no angular math.

AO uses break point tables. That is a certain. The item database is a huge break point table and all items between two QL entries are extrapolated. AO uses CTree database files which are VERY fast at look ups. Simply put they have break point math and routines in place. If they can reduce the math load on the server by pre-computing large parts of it and saving it off in tables for look up operations then the overall savings on performance will be noticable. Reduced server lag is the best way of saying it. I really suspect they have done this for at least parts of the math operations.

Is the hit/miss calcuations part of that or not? I don't know.

It has been fun having this discussion with you. I have enjoyed that it stayed a discussion with strong view points and yet polite. As I suspected you are a professional person and like me just want to understand it all in the end.

[Ebag333]

Though I think that the difference in toatal defense rating between our two equations i probably going produce results that are inside your +- 5% error rate.

I'm not sure how that could be true. Why would we see less than a 5% margin of error when we're seeing up to nearly 40% of the total defense being AAD?

That's a huge amount of AAD. If the Agg/Def bar didn't effect AAD, one would assume that it would have ~60% of the effect for the higher AAD tests.

At full def, with 50% Diff AR %, you have a land rate of about 63.07%. At full aggro, you will have a land rate of 94.6%.

That's means that the agg/def bar had an effect of 31.53%.

If it only effected evades and not AAD, that means that my tests with a toon that the def was made up of 40% AAD *SHOULD* have a land rate of 12.612% different. That falls well outside the 5% margin of error. That should be easily distinguishable....it's not.

Depends on the math you use. Your example is pretty far from how we use them. The basic idea is this.

That is very very true. Break point tables can be very fast, as long as they are limited.

I think you're assuming a very long equation for calculating hit rate, compared to a comparatively small break point table. Actually, the equation is pretty small. Whether it's faster than a break point table.....who knows.

Either way, as I said, whether it's a break point table or a formula (or a combination of the two), it doesn't really matter either way. The results end up the same.

I've always known I would never be able to duplicate what FC has. But my goal was to mimic it.

It has been fun having this discussion with you. I have enjoyed that it stayed a discussion with strong view points and yet polite. As I suspected you are a professional person and like me just want to understand it all in the end.

I try to be at least.

Any way you cut it, it's a fascinating discussion.

[Lheann]

Any way you cut it, it's a fascinating discussion.

True. Sadly I enjoy these type of discussion far more than sports ones. Save hotrods and fishing this type of stuff is my passion.

[Ebag333]

and fishing

Bass or trout?