Requesting Data for Parry RATE (not amount mitigated)

[spelley]

Miss would only make sense to go BEFORE everything else, as all the other calculations can be skipped (and thus be more efficient) in the case of a miss. So the order should be:

Miss% -> Crit (since it is never effected by Block or Parry) -> Block (evidence to prove Block > Parry) -> Parry

You do it this way so you can ignore/skip the rest of the chain, and thus be more efficient, the moment one of the flags is thrown. IE: If it's a miss, there is no need to calculate whether it could have been a crit/parry/block etc.

As a programmer, I'd definitely have each as their own separate roll. If you have it in a table, you have to calculate the whole table at the start each time, instead of having a couple of smaller operations that only conditionally need to be made IF they are applicable.

[Zfz]

As a programmer, I'd definitely have each as their own separate roll. If you have it in a table, you have to calculate the whole table at the start each time, instead of having a couple of smaller operations that only conditionally need to be made IF they are applicable.

Just want to say this again, there is no actual table lookup. The actual code could be like this:

r = random(1);
r = r - missrate;
if (r<0) then { //miss }
else {
  r = r - critrate;
  if (r<0) then { //crit }
  else {
    r = r - blockrate;
    if (r<0) then { //block }
    else {
      r = r - parryrate;
      if (r<0) then { //parry }
      else { //regular hit }
    }
  }
}

j

There is no table to calculate. While the concept is a table, we don't go mindlessly implement a table lookup. The effect of this implementation is the attack table. When you activate Awareness, the buff management code sets that critrate at 0 and the above code runs happily with no additional checks and magically results in 0 crits. When Awareness wears off, the buff management code puts that critrate back to what it should be, and viola you will eat crits again. Since the buff management code is outside of the combat resolution loop, it is more efficient than checking on every attack whether you have Awareness up or not.

The various rates are the exact same rates you would roll against in their own seperate roll. To change that code to a multi-roll model, you just replace all the subtractions with "r = random(1);", and replace all the if conditions with "if (r<___rate)":

r = random(1); // roll a number between 0 and 100%
if (r<missrate) then { //miss }
else {
  r = random(1);
  if (r<critrate) then { //crit }
  else {
    r = random(1);
    if (r<blockrate) then { //block }
    else {
      r = random(1);
      if (r<parryrate) then { //parry }
      else { //regular hit }
    }
  }
}

----

In any case, now that we have the priority list, we will need to find the miss/crit/block rates before we can actually calculate a constant "parry -> parry rate" conversion at level 60. Although we can just look at the real rates, that real rate will change depending on our miss/crit/block. For WAR/DRK it doesn't change because of zero block, but for the PLD, every time we upgrade a shield, our real parry rate per point of parry drops.

At 322 block and 530 parry, we're looking at real rates of about 18.5% block and 11% parry.

I'm starting to think data collection should be more complete with total swings, crits, blocks, parries all recorded. Otherwise we may not notice anomalies that may point to more intricacies of the system.

[Yorumi]

snip...

Just wanted to add a little extra logic here. I have no idea how ff14 implements things but, it's worth mentioning that although small, rolling a random number does require cpu time. Again minor, but the single roll algorithm is more efficient than the multi-roll algorithm. Given that it's an MMO server, produces essentially the same outcome, and is more efficient, I have trouble seeing any real reason a programmer wouldn't do a single roll system.