Kraken Club Offhand Hits Per Round Simulation

Copy and paste the code into this online IDE: https://repl.it/languages/python3

Modify your QA, TA, DA, FUA, and Hit rates. And set AM3 and Kraken offhand variables to either True or False then run it.

Advantages over spreadsheet math: Exact functionality of how it would act in game involving hit rate cap and FUA mechanics.

Disadvantages: You don't get the same answer every time (just like in game,) and therefore you have to think for yourself.

Curious why you say that the spreadsheets don't use exact functionality regarding hit rate cap and FUA mechanics.

Considering most people trying to add or modify things to one do it in the most idiotic ways, all the ones I've seen don't. FUA took forever for people to understand it's just a simple addition. But if you have a formula for capping off hand hits based on main hand, I'd be interested to see it.

And since they take an average of everything, nothing is exactly as it would be in game.

The base version of Motenten's spreadsheets already includes scrapping excess offhand hits if both hands' combined swings would surpass the 8 hit cap. If I go into Melee tab and set the mainhand number of hits to a 100% chance of 7, having the offhand go from a 100% chance of 1 hit to a 100% chance of 2 hits doesn't affect DPS at all.

Your iteration based method doesn't truly match what we get in-game either, just because the RNG rolls will never match what the server gives you. No method of simulation will actually predict what will happen hit by hit in-game.

I'm actually working on something very similar in Python for simulating DPS based on provided/generated WS/TP sets. I have a few silly questions about this that I can't test myself because FUA and Kclub are expensive. I forgot FUA was a thing and have not thought about implementing it into my code until now. How exactly does FUA work? Does it apply only to the hand that holds the weapon with the augment? Similar for Kclub. You only have the Kclub check on offhand, does the hand not wielding Kclub receive its benefit?

Does FUA apply to both hands in weaponskills? What about Kclub?

There's a potential typo as well: you're using
which ranges from 0 hits to 7 hits in Python. Did you mean to use range(1,9)?

(Edit: not a typo, I'm just dumb. See below.)

When it procs, it's an additional hit. It's independent of QA, TA, or DA.

Yes.

No.

No. The initial offhand swing is already accounted for in the melee_round() function, kraken can only allow 0 through 7 hits, which is why the range is 0 through 8.

I mean, that just implies you didnt simulate enough rounds.

If you simulate it for long enough, you should get pretty close to the exact same answer everytime for the same input.

Just substantially increase the amount of simulated time it runs for and that "disadvantage" goes away.

Thats how the DPS spreadsheet works. It basically takes every single possible iteration of hits you can do in a round from 1 to 8, for both offhand and mainhand, and the percent chance that specific iteration might occur, so you get he complete average spread of average hits per round exactly.

This can be seen under most DPS spreadsheets "Melee" page

Could you go into more detail about this? I think the idea with the code above is to return range of values from which the user can draw for a simulated TP round. Increasing the number of simulated trials should definitely return what you get in-game over a similarly large number of trials if coded properly. I'm working on this very same problem for personal use/fun so any additional info would help.

Ah, right. I forgot you were adding bonus hits, not total hits. Thanks for the answers.

Austar was being flippant; he doesn't consider that to actually be a disadvantage.

This particular bit of code runs 10K iterations. Iterations aren't the issue, the more variables involved the wider range you're going to have. You can use my full SAM DPS simulation and run the 10K fights it runs and see the upper and lower end being almost 25% apart at times. Likewise, you can do the same fight 10K times in game and not parse the same every time.

I disagree. Having the extra information means I can make smarter choices in gearing. By having all the information and the ranges, I can eliminate outliers and focus on reducing the variance and maintaining the close to optimal average, which requires more thought than just changing some stuff in a drop down box and getting one number, and why most people don't care to use a simulation. A simulation also can provide more accurate information for things not easily done in a spreadsheet, such as Karambit's unique effect. What if my MNK doesn't start with 3K TP? What if I'm fighting apex mobs and want a realistic 3 second delay between each mob? What about staggering job abilities or weapon skills based on buffs? Sure, you can do half *** ways in spreadsheets but there is more human error there. Almost no advantage of a spreadsheet other than ease of use.

You can also stagger job ability and WS setups using the spreadsheet, and I personally believe trying to include such wildly varying and unpredictable human-error related adjustments (like time between kills) is trying to take math-based simulations outside of what they're actually capable of accurately simulating. As soon as you pick a "realistic" 3 second delay between fights (or any other value), you'll be confronted by the reality that this type of parameter can't be accurately predicted. It'd be like trying to program into a simulator a low chance of getting a call from your boss and having to go afk for 2 minutes, or the chances your white mage will be distracted and let haste fall for 15 seconds instead of renewing it before it wears.

Spreadsheets can't include those types of situations, but I personally feel that the spreadsheet being very accurate in its own domain (more accurate than an iteration-based method, because calculating the average is mathematically the same as having an infinite number of iterations) is more important than trying to overextend a simulation's attempted domain and have lower accuracy (because adding variables that can't be reliably correlated with real life effects lowers accuracy) in the process. If you say, try to account for 3 seconds in between fights and the group you're in actually takes 8 seconds (or wildly varies between 0 seconds and 30 seconds), the adjustments you made based on the simulation could end up hurting you instead of helping because they're so tailor specific to inaccurate details you added.

I must've missed the comment you're replying to since I can't see it. But I also think the iterative/simulated method is better for specific situations where an average/median isn't an accurate representation of the damage actually being dealt per weapon skill. Weapon skills with low FTP and a lot multi-attack have many peaks, and critical hit weapon skills generally have two strong peaks.

For example: if I run a few simulations for my Blade: Hi set on Apex Toads without buffs, I get a double-peaked distribution. It turns out that the median value obtained is actually one of the values least likely to occur. Over many trials the average on a spreadsheet and through this simulated method will return the same value, but in a short in-game fight, I'd like to see what my full range of damage is.

It seems to me like you just can't understand or want to understand.

And with that information, you can eliminate the outliers and change your gear around to reduce the variance while maintaining the same (or close to,) median and average.

Some factors of a simulation may not be accurately predictable, but that doesn't mean it's better to ignore them entirely with a spreadsheet. A properly coded simulation will always be preferable to a properly coded spreadsheet in the format we are accustomed to(obviously it is possible to run a sim through a spreadsheet with enough time invested into it).

Right.

That means 10k is exceptionally too small is all.

Try something closer to the billions range and you'll, as I said, see the lows and highs converge to the mean.

If your simulator is showing a wild 25% change in DPS each time you run it, thats not very useful then. I would expect a proper DPS simulator (that I intend to use for meaningful gear choices) to have less than a 0.1% variance each time I run it.

Any more than that and it isnt super useful, at least in terms of applying it to the task of "Which of these pieces of gear is better?", because a 25% varience means I couldn't possibly tell if my DPS changes between runs were because of the gear, or the extremely low sample size.

When Im testing two peaces of gear against each other to compare and that DPS difference is going to be <1%, then the simulator's variance per run needs to be a fraction of that.

So you don't really understand either. Simulations aren't an infinite duration fight. I can adjust my fight duration as long and as short as I want. Most of the ones I run are realistic 3 to 10 minute long ones or a couple hour ones with engage delay variables.

Go out and do 10K of the same fight that is 5-10 minutes long and tell me you only have a 0.1% difference then come back.

As for which piece is better, that's where having some actual intellect comes into play. Most of the top end pieces aren't going to show you different results in game either. The point of the data from a simulation is to use it properly. Reduce the variance in your runs while maintaining your mean and average as best as you can.

Your DPS as a player is not something that exists in a short finite fight, each fight existing as a separate instance of finite logic.

Like, lets put it this way.

Lets say you play a game, where you and other players roll a chosen dice from a pool 5 times, add the total score up, and then whoever got the highest score wins. Its an extremely simple "game" but demonstrates the point.

Now there exist many different dice in the pool to pull from, all sorts of different shapes, sizes, side counts, and some of them arent even numbered continously (some dice are numbered from -10 to 1000, others from -1 to 10, some from -20 to 20, some from 5 to 1000, etc)

To such a degree its actually kind of hard to tell which dice are "the best" at a glance, since they are so wildly different and variety in shapes and sizes.

However all these dice exist in a box, and the pool of dice is finite, it never changes. You even have access to this box in your home when not playing the game, its just sitting in your cabinet.

So, you realize, you could perhaps, when your guests arent over, find out on your own time which dice are the best, perhaps, by performing many rolls with them and recording the results.

Here's where your logic is breaking down.

Imagine if I performed 100,000 rolls with each dice and recorded their mean scores they rolled in a spreadsheet, and thus could rank them from best to worst based on that mean score, then next time I play with friends, all I have to do is reach for the dice with the best score I found prior, and Id have logically the highest chance of success.

Now imagine if your response to that was "Ok but you only get 5 rolls during the game, not 100,000, therefor you're spreadsheet doesnt reflect the reality of the situation"

Which is false.

The entire point of simulating your dps for billions and billions of rounds is so you can make informed decisions on very small scale upgrades that normally are so small, you wouldnt be able to tell (via the human eye) that they were doing anything for you on small scale fights.

But they are still improving your DPS, but the improvement is so marginal, you need to see it on a larger scale to actually see it.

Thus, I can do 100,000 dice rolls with those dice, so I know which dice truly is the best of them all, so then when I only do 5 rolls with it, sure, I might still not win perhaps, but, my odds of success are the highest

Just because fights only last a couple minutes in FFXI, is not justification for your DPS simulation to only do the same.

If you do that, then your DPS simulation is, as far as I am concerned, not helpful.

The entire point of a DPS simulation (traditionally) is to simulate hours and hours of fighting in a matter of seconds, letting me see "the big picture"

But honestly all of this means very little because in actual practice, the truly strongest DPS stat is Meva, which not a single DPS simulator of any type anyone has made here takes into account :p

Well, you can lead a horse to water.

Actually, the point is to prove that the differences between some pieces are so minute, it won't matter which you pick since it won't make any difference simulated or in-game. You don't fight the same mob with unchanging variables for an infinite amount of time with the same and incorrect values a spreadsheet will give you.


That's precisely the point of having an option for only a few minutes.

How long do you think 180 second long fights are if I do it 10 thousand times? That's 30K minutes, 500 hours. I can change however long and short my fight needs to be. I can also choose an HP threshold instead of a time base, to see how long it takes me to do X amount. Or, I can do both, simulating something such as farming CP and even add delays between mobs, reducing the effects of AM3. Additionally, I can alternate JAs properly, build AM3 properly, skillchain properly, almost anything with accuracy you will never get with a spreadsheet because you're just hitting a wall with infinite health for infinity. In addition to that, the fact that literally everything is averaged is going to give you incorrect values where it shouldn't.

Even if you had zero variables and had infinite attack on a level one mob, you'd still have 5% variance between your upper and lower end damage.

I like what you've done here. I have a question. In lines 31,33,etc, you call "random.random()" ...but is this random value something you should calculate once per attack round? or is it correct as you currently have it written? (that is, you generate a new random value upon checking for QA or TA proc.)

Which is a more accurate determination?

The current belief is each proc is checked separately, which would make the most sense, which is what I have implemented.

@Austar I doubt that Soralin has taken statistical methods, not to put too fine of a point on it, but 10k samples is a mammoth N value and the confidence level is well beyond .1%.

Without the understanding of those mathematic principals it's not unexpected that he doubts the math, but he wouldn't know where to look to find an error.

@Soralin without the EXACT mechanics, the best that can be done is an approximation, in that regard the further off his method is from the real life calculations, the less the data set can be compared (outliers in the data will corrupt the averages by some value).

To make that worse without knowing the exact mechanics SE used and the method he used there is no definite way to tell how accurate his data represents the item in game. (this is an inherent problem with predictive statistics)

Nothing says "I totally know stats" like opening up by trying to undermine the other persons knowledge with a veiled insult, then following up with confidence levels as if thats your trump card. Thats basically day one of stats, congrats, now then...

>without knowing the exact mechanics SE used and the method he use

Except we do know his method because he literally has the python code posted...

As far as I see, I dont see inherent flaws in his code, it looks like it mirrors our model of how we believe multi-hit to work.

The issue lies in the fact that each variable exponentially increases your error, in your formula

You have to take the entire multihit formula as a whole and apply error propagation to it.

So, if you're not gonna sit here and produce the completely integrated error propagation formula for the multihit formula, please kindly take your "statistical methods" insults and sit the *** back down, kthx? Because anything short of that is not contributing at all and indicates a total lack of depth.

Here, because the formula isnt terribly complicated, I made a simple mockup calculator that doesnt rely on RNG stuff to quickly and easily punch in your values into.

https://docs.google.com/spreadsheets/d/1tU5UtlEk5aHEyoTrR82FxdPHJLxkExu-lSa60OiQf6A/copy

All you have to do is modify the values under "Variables to suit your needs.

We are exceptionally confident on how the multihit formula works, it has been tested to death, and it isn't terribly difficult to calculate your exact average hits per round with it.

Ive broken the sheet up into some pretty straightforward sections, should be easy to follow how it works.

Ill add some notes to sections as well, to make it easier.

its just like in game, i don't get why this is so difficult for you. even without any amount of multi hit and auto attacking a wall for hours, you'll have variance.

your spreadsheet doesn't, why should my code?

as far as your hit/round sheet, nobody said the formula was hard. you also lack follow up attack, is that because you can't copy and paste it from motenten's spreadsheets?

I also did the same thing you just did in 4 minutes, assuming kraken offhand:

Iteration-based simulation only proves that the random variance within any reasonable amount of fighting is greater than the difference between two similar pieces of gear, which is obvious.

Just because a player can't eyeball the difference between two similar pieces or that bad RNG rolls with better item A will make you perform worse than good RNG rolls with worse item B doesn't mean that one piece isn't better than the other under the circumstances in question, or that it's impossible for the difference to swing a battle in one direction or another (as unlikely as it is).