Requesting Data for Parry RATE (not amount mitigated)

[Ultimatecalibur]

So there's absolutely no evidence whatsoever to prove that the FFXIV game resolves combat events in one way or the other?

Firestarter/Thundercloud and Split/Slug shot Procs pretty much state that there are at least 2 rolls made, the fact that we can get multiple individual item drops from kills implies that they are not using tables over multi rolls for drops, and the method that Shelltron operates on in respect to Crits as mentioned would not happen the way it does if it was a table.

This is also very simple to program and actually makes the end result match actual probabilities of each of the events.

Enemies (of different levels at the least) have different accuracies (which can be proven by letting yourself be attack and tracking the amount of misses) and can be individually blinded. You would need to have individual table for each mob and each mob would need to have and maintain an individual table for each target it was attacking or catching in its AoEs. That is a lot of data and table management that would need to be programed in. A stat based multi roll If:Then:Else tree is much simpler to program and far less data intensive.

In single-roll resolution, suppose a miss rate of 15%, crit 5%, block 20% and Parry 10%, then 50% of all attacks should be regular hits. But with multiple rolls, it means that all regular hits are actually the event "not miss && not crit && not block && not parry", giving you the end probability of 0.85*0.95*0.8*0.9=0.5814, i.e. 58%.

I'm not quiet certain of what you are trying to say here. Yes, single-roll resolution makes for prettier statistics, but pretty statistics are not really that important to a computer. I would not be surprised if the RNG roll used a whole number between 0 and 255.

If the game is using a multi-roll system, we would have to find the miss and crit rates before we can find the actual parry rate used in the calculation, because our data would only give us the rate at which the attack "wasn't a miss and wasn't a crit and was a parry" (assuming we remove the shield in our tests).

No, at the most we need to find the number of crits in the hit total (as the misses will not be hits and will already be factored out of the attack total to create the hit total) and remove them to find out the number of attacks that can be blocked/parried.

[Zfz]

Firestarter/Thundercloud and Split/Slug shot Procs pretty much state that there are at least 2 rolls made, the fact that we can get multiple individual item drops from kills implies that they are not using tables over multi rolls for drops, and the method that Shelltron operates on in respect to Crits as mentioned would not happen the way it does if it was a table.

I'm not sure I understand why Firestarter necessitates a multi-role attack resolution for physical attacks. It is not unheard of (in fact WOW uses two-roll system for magic attacks and one-roll system for physical attacks) to have magic and physical attacks work differently. The rules for drops also doesn't necessarily mean anything for attack resolution.

EDIT: Even with Split/Slug shots, they are procs, not attack resolutions. Why do they necessitate a multi-roll model?

And in my attack table method I already illustrated that it will give you the exact same results from your tests. When SheltronRaw Intuition is activated, in your multi-roll scenario it works like this: (let's ignore block for now because it's just a different form of parry for us)

Parameters: Hit=85%, Crit=5%, Parry=100%.
Hit roll 56 (56<85, a hit) -> crit roll 3 (3<5, a crit) = crit, resolution complete.
Attack ends up as a crit even though SheltronRaw Intuition is active

and in my attack table scenario it works like this:

Parameters: Miss=15%, Crit=5%, Parry=100%.
Roll 18.
Check miss 18-15=3, 3>0, not miss.
Check crit 3-5=-2, -2<0, a crit. Resolution complete
(It doesn't get to check parry, exactly the same as your model.)

You see, when we say "roll", it means physically "roll a new random number". A multi-roll system means rolling a new random number each time you check for the next possible result. A single-roll "attack table" system means that one number is used to determine where your result is.

Think of the attack table model like throwing a dart with the target circle divided into the different results.
Think of the multi-roll model like throwing a dart at several different target circles of varying sizes.

Enemies (of different levels at the least) have different accuracies...A stat based multi roll If:Then:Else tree is much simpler to program and far less data intensive.

I think you misunderstand what I meant by the attack table system. Perhaps you know it by some other name. Or maybe I should call it the attack table model. As illustrated with my example above, all that is required are the exact same data your multi-roll model require. Do your multi-roll model not need to specify the hit rate for each level difference? That same hit rate is used without any additional processing requirement in the attack table model.

The attack table model is called not because we actually go list every possible roll outcome and do a look-up as if from a table of results. Actual processing requires only knowing the thresholds, and the only difference between your model and the attack table model is that when you are rolling new random numbers, we are doing a subtraction. We still go through the same if-else structure.

But what is easier is irrelevant. What we want is actual evidence of the system, and none of what you mentioned disproves the attack table method.

I'm not quiet certain of what you are trying to say here.

I'm saying that in a multi-roll model, the individual probabilities do not equal to the actual in-game result.

In your specific multi-roll model, a parry rate of 10% (let's again ignore block) is actually the event of "hit && not crit && parry", and using the above example parameters of 85% hit rate, 5% crit rate, this event has the probability of 0.85*0.95*0.1=0.08075, i.e. only 8.075% of the swings taken at you will end up as parries. Meaning when we take our data, with a 10% parry rate on our character info, our data will show about 8% parry rate instead. That is why it was suggested that we remove the misses and the crits when calculating the parry rate from the data.

In a single-roll model, 10% parry rate on our character info will give us about 10% of the swings ending up as parry from our data. Removing misses and crits from the data will actually skew our result.

So it is important to know what system we're working with, if we want to find out exactly what parry rate we gain from every point of parry.

[Ultimatecalibur]

Its more about when the buff is applied and triggers.

An IF THEN ELSE chain would do the following when checking an attack*:

If Awareness = True THEN [Crit = 0] ELSE[
If RawIntuition = True AND Position = Flank or Rear THEN [Crit = 255] ELSE[
Crit = "Crit Formula"]

If RNG < Crit THEN [Critical Hit] ELSE [

If Shelltron = True THEN [Block = 255, Recover X MP, Remove Shelltron] ELSE[
IF Bullwark = True THEN [Block = "Block formula"+153]]

If RNG < Block and Position = Front THEN [Blocked Hit] ELSE [

If KeenFlurry = True THEN [Parry = "Parry formula" + 204] ELSE [If DarkDance = True THEN [Parry = "Parry formula" + 51]]

If RNG < Parry and Position = Front THEN [Parried Hit] ELSE [HIT]]]]

*It has been ages since I actually last programed as so this should not be taken as "it must be this way" its an illustration of a possible way to do it.

In your single roll model Shelltron would either need two steps (one before the roll to modify the table and one after to proc off the block) in order to trigger or would always trigger on the first physical attack after it was used.

I'm saying that in a multi-roll model, the individual probabilities do not equal to the actual in-game result.

In your specific multi-roll model, a parry rate of 10% (let's again ignore block) is actually the event of "hit && not crit && parry", and using the above example parameters of 85% hit rate, 5% crit rate, this event has the probability of 0.85*0.95*0.1=0.08075, i.e. only 8.075% of the swings taken at you will end up as parries. Meaning when we take our data, with a 10% parry rate on our character info, our data will show about 8% parry rate instead. That is why it was suggested that we remove the misses and the crits when calculating the parry rate from the data.

We are only seeing the final result (was an attack parried or not) and only can see one of the variables. There is nothing telling us X Parry value = 10% Parry. All we know and have been told is that a Program uses our Parry stat and character level and a Random number to determine if we have parried or not. The X% parry numbers are percentages based on parsed data. Nothing in game tells us our Percentage Block Rate or Percentage Parry Rate.

[Zfz]

Its more about when the buff is applied and triggers.

Which does not have to be tied into combat event resolution.

Let me just ask you one question on the pseudo-code you presented. In these three statements:

If RNG < Crit THEN
If RNG < Block and Position = Front THEN
If RNG < Parry and Position = Front THEN

are all three "RNG" the one and the same random number? Or do they represent drawing 3 different random numbers?

If you draw one random number, then you have been talking about the one-roll attack table model all the time. And if you re-draw a new random number when you check for each of Crit/Block/Parry, then you are talking about a multi-roll model.

The point I'm trying to make, is that having multiple procs and drops from the same combat action do not necessarily dictate that the different outcomes of the same combat action must be multi-roll.

We are only seeing the final result (was an attack parried or not) and only can see one of the variables. There is nothing telling us X Parry value = 10% Parry. All we know and have been told is that a Program uses our Parry stat and character level and a Random number to determine if we have parried or not. The X% parry numbers are percentages based on parsed data. Nothing in game tells us our Percentage Block Rate or Percentage Parry Rate.

A multi-roll system will mean that every 1% rate increase of stats for a higher-priority outcome will diminish the value of 1% rate increase of stats for a lower-priority outcome.

For example, suppose 15% miss > 5% crit > 20% block > 10% parry > remainder being regular hit. Suppose that is the probabilities you end up with your gear. We don't know these probabilities, but we know the amount of stats we have. Taking in-game data, we will see:

• in a multi-roll system, 0.85*0.95*0.8*0.1=0.0646=6.46% of the swings end up being parry;
• in a single-roll system, 10% of the swings end up being parry.

Now increase block from 20% to 30%, and again taking in-game data, we will see:

• in a multi-roll system, 0.85*0.95*0.7*0.1=0.056525=5.65% of the swings end up being parry;
• in a single-roll system, still 10% of the swings end up being parry.

Hence in a multi-roll system, you want to maximize stats that contribute to a higher priority mitigation outcome (in this case, Block is more valuable than Parry), unless the mitigation from a lower priority outcome is extremely strong (for example if parry was 50% mitigation, then you would want to exchange as much of your block rate as possible for as much parry as possible). In a single-roll system, all mitigation outcomes grow independent of each other until you have enough of the high-priority outcomes to push the low-priority ones off the attack table.

(As an aside, that's what tanks in World of Warcraft once was able to do: to push regular hits off the attack table so that 100% of all hits are mitigated.)

This is why it is important to investigate the combat resolution system. It will change the relative values of the defensive stats and how you gear your tank.