All Jobs Damage Simulator And Gear Sets

No, if the sets are suggesting using thief's empyrean hands for sneak attacked weaponskills then they most certainly are NOT calculating correctly. The formula for sneak attack + rudra's damage with the empyrean hands is calculated as follows

floor((((floor(Weapon Base Damage + fSTR + (0.8 x Dex)) × fTP) x WSD) + Dex x 1.3)

I bolded the section where the sneak attack dexterity bonus and empyrean hands bonus get applied to a stacked weaponskill's damage. It gets factored OUTSIDE of any WSC or fTP bonuses. So if your dex is 450, then empyrean hands are literally just adding an extra 135 base damage to an attack that already has in the range of 5-7000 base damage. Empyrean hands are complete trash for a sneak attack weaponskill. Nyame Gauntlets are vastly superior in every situation. You always want the WSD.

And yes, when you're looking at a trick attacked weaponskill you substitute agility in the same spot dex goes for sneak attack. The artifact gloves bonus for trick attack is equally worthless for a stacked weaponskill as the empyrean gloves dex bonus is.

Do you have any source on that equation? I believe you since I remember being surprised by how much the code boosted damage with SA/TA at low buffs, but I'd like a source before I make any large changes, even if they're as easy as moving a few variables over in one equation.

I currently have Sneak/Trick attack and flourishes apply before WSD, PDIF, and crit damage.

BG Wiki only says "the DEX is added to base damage after the fTP multiplier is applied." Flourishes say "outside of the WSC term." Neither mention where the bonus is applied in relation to PDIF or WSD.

My understanding is that "PDIF" boosts your "Base Damage," while "weapon skill damage" boosts the final damage of the weapon skill after all other terms have been included.

The BG Wiki page for Base Damage places the DEX/AGI/CHR boosts from SA/TA/Flourish within the base damage, which suggests that they get boosted by PDIF and WSD.

Pdif is calculated at the end of everything. Dex is just added outside of WSD and fTP bonuses. This is the full formula. Simonsays, Eiryl, or Thorny can all probably confirm, as can several others I'm sure. This has been known for a very long time. It's the reason nobody uses the empyrean gloves.

(((((Weapon Base Damage + fSTR + (0.8 x Dex)) × fTP) x WSD) + Dex x 1.3) x pDIF

Yeah, that's it. With high base weapon damages and WS modifiers now, the DEX from Trick Attack ends up being a pretty trivial addition and iirc the hands aren't even worth using.

I like this idea, and it turned out to be much easier than I initially thought to add a "first attempt" version of this feature.

I've added a checkbox to the Outputs tab that lets the player enable/disable showing potential swaps within x% damage of the best set; the user defines x in an input box beside the checkbox. The format isn't great, but I've updated the code on GitHub with the changes since it's still neat to play with. I'll probably update the way the results are displayed later.

As an example, since we saw in an earlier post that RDM Sanguine Blade has a lot of potential neck options, I ran the Sanguine Blade set again with the same buffs and told the code to spit out the one-item swaps that are within 1.0% of the best set. The new output (with the new checkbox enabled) shows:
This should help illustrate, at a glance, how close many of these "best" items are to other items that people may assume are significantly worse.

This function only checks how swapping a single item affects damage for WS, ranged, and magic attacks; it will not check double-swaps or TP sets (yet). I've had the code ignore the back slot (because it would print dozens of ambuscade capes with 0.0% difference right now), and the main+sub+ranged slots, since these are generally locked anyway. Ignoring the ranged slot means that BRD will not automatically find good ammo swaps for Linos, but that requires two swaps anyway. You'll have to manually check these slots.

Since this is only swapping one item at a time to find potential swaps, it will not, for example, equip two pieces of Amalric for the set bonus. You'll still have to check set bonus swaps manually. It will correctly apply the set bonus if one piece is already equipped and it swaps in another, though.

I realize the player's stats are currently being pushed out of the window in the outputs tab as I add more checkboxes. I'll move these stats to a new tab in a future version.



I have no plans to add +1 or +2 JSE or NQ Sortie earrings.

Adding new gear is easy, but you must have Python installed and use the gui_wsdist.py version of the code. I gave an example of how to add Haubergeon in an older post in the original thread. I should put a summary of that response in the original post so it doesn't get lost here.

There may be a way to exclude the gear.py file from the compiled version of the code so that it can be modified while still using the gui_wsdist.exe version of the code. This would be most convenient for users if it is possible. I'll look into it later.

1. I've added off-hand versions of the SU5 weapons without augments.

2. I've added a separate entry for PDT and MDT requirements to the Outputs tab. For future reference: adding a third condition (like subtle blow) will likely require swapping three items at once. We can get away with PDT+MDT separately because we swap two at once now.

3. This was covered above. Check out the original post about this. If you're using the gui_wsdist.exe version of the code, then you can't make any changes. You must run the gui_wsdist.py version of the code like a normal Python file to see any changes you make to the other .py files.

4. Outputting the currently equipped set to a text file would be very easy to do, but it would likely not export the names in a way that gearswap likes. I might add this later.

Thanks for the quick reply. I've updated where Sneak/Trick attack and Flourishes are added to damage in the code. Physical damage now uses the following equation:

I would still like to see a source on this, or perhaps some testing results. The THF community seems agree that equipment which enhances the SA/TA modifiers is not worthwhile, so you're likely correct. It's just weird that there is no easily accessible source that shows where to apply the bonus in the damage equation. At the very least, it's easy to unfix the equation if what I had originally was the correct equation.

I'll update the THF and DNC stacked WS swaps later.



A new version of the code has been uploaded with the above changes. As always, keep letting me know if you notice any potential issues or have some suggestions. Hopefully I didn't break anything while making the adjustments mentioned above.

It's been known for a very very long time. Like.... well over a decade. I just pulled up an old guide
from 2007 that has the same formula. This is a quote from that old guide


That's from about 5 years before abyssea ever even existed. We've mentioned it ad-nauseum on the forms so often that it's probably scattered about dozens of places in multiple threads over the years. I've been a thief main since 2005, so I just kind of know it to be true by now. There have been tests that back up the math on more than one occasion. That's just where the mod goes in the formula. It was a lot more relevent back in the old days. When abyssea first came out the gloves bonus was actually quite a big deal because back then you only got like +6 and +7 dex on a single piece max, and at the time rudra's wsc was 3.25, 4.25, and 5.25, so it didn't scale nearly as hard as it does today. That changed in 2014 with the weaponskill update, but that's getting off topic now so I'll belay the storytelling and leave it at that.

Dang, you're quick! Appreciate the feedback / updates.

I got the Python version running and have been playing with that. I have a total of about 2 hours of experience with python so still just stumbling through everything at the moment. Is there any major drawbacks to comparing more than 2 pieces at once? I would assume it just takes longer to run? This is already amazing, but adding options for minimum requirements outside of PDT and MDT would make this even more useful when trying to make different levels of specialized sets.

I also noticed all the Ambu capes have -5DT, when I usually go for -10PDT since shell caps MDT so quickly. Would it be possible / worth the effort to add a way to change that within the GUI? I changed it to -10PDT in the for loop that makes all the capes, but would be useful to have options for the resin augments that can be changed on the fly. This is an extremely minor / quick update on the users end to have capes with the desired aug... just thinking out loud here.

TP Bonus from ranged Aeonic weapons only applies to ranged WS's. It looks like it's being used in all WS damage calculations at the moment.

I've mentioned the method I use to him, but I don't know if he's really interested since it would require a lot of re-writing of code.

I haven't played around with the code yet but this output is not what it should be: Sroda Tathlum is a 10% chance of final damage being multiplied by 1.25, so the Minimum and Maximum values should be different there.

From what I can tell, it appears that the "maximum" and "minimum" themselves are average numbers.

I noticed this when I was testing the effect of resist. As I increased the magic evasion of the mob, expecting to see more and more half resists, it turned out that the program instead returned a gradually decreasing single number for Sanguine, to ultimately 1/8 of the original number when the magic evasion was ridiculously high, indicating that every WS is fully resisted.

So I guess the program runs several tests, each tests calculating a certain average damage. The highest of these is the "maximum", the lowest being the "minimum", and the average of these averages is the "average" shown in the result.

Since you're now an expert with Python, you can choose to have the code swap up to three items at once! Go to line 1130 of wsdist.py and change the "fitn=2" to "fitn=3" to start swapping up to three items at once. It's been a while since I tried to swap three at once, but if you choose to do this, then be aware that it will probably take at least 30 minutes to find one gear set, likely much longer if you use the "Select All" buttons to automatically select all gear. If you add DT requirements with three swaps, then it will likely take a few hours to find one set. I recommend manually selecting the pieces of gear to check if you use "fitn=3" so it doesn't test stuff like Mujin Band for Blade: Ten.

I originally planned to let the user decide to swap 2/3 pieces at once, but I believe swapping three will take much longer to run than people are willing to wait for small gains in set accuracy. Adding support for 4/5/6/etc is very easy and only requires adding another for-loop for each additional swap and tabbing over the existing code, but the run time increases exponentially with each additional swap.


Edit: I remember doing the math for your method and it would take something like 45 days to find one gear set due to how many items the code includes. Manually selecting only a handful of items would get around this for the most part, but it would likely still take many hours of runtime for one set.


Adding an option to let the user choose two conditions to satisfy shouldn't be very difficult since it should only require adding a few lines of code or cleverly rewriting even fewer. The problem is trying to place more than two constraints at once when we only swap two slots at once.

For example, if we want a set with x PDT, y MDT and z Subtle Blow:
The code will try to find a set that has 1 better PDT, MDT, and Subtle Blow than the previous iteration found and will reject sets that do not. Since the code only swaps two items at once, it must find two items that together increase all three required stats by 1, otherwise it will reject the set. There are not many combinations of two pieces of gear that have PDT, MDT, and Subtle Blow, so it is not likely that the code will succeed in satisfying the user's conditions. If we had access to three pieces of gear, then we could find one piece with PDT, one with MDT, and one with Subtle Blow very easily and slowly build up to their required values.

If we set up the code to satisfy one condition at a time for a total of three conditions, then it would either take approximately 3 times longer to run (so maybe 10~15 minutes for one decent DT+Subtle blow set), or it would begin removing PDT pieces to fit in Subtle Blow pieces and never technically satisfy all three conditions. Satisfying each condition separately would also require a fair amount of rewriting that bit of code.



Having PDT on Ambuscade capes was requested a while ago, and I thought I fixed it, but clearly I forgot to change one line which still gave DT-5 to most capes. Either way, it's been fixed (probably).



Sroda Tathlum is a case of me being lazy making it a 1.025 damage multiplier, rather than running another random number generator if it happens to be equipped.

The output of the code listed in the code spoiler for Sanguine Blade prints the minimum, mean, median, and maximum values encountered after x proper weapon skill simulations, where x is the number you enter on the outputs tab that currently defaults to 2000. These are the results for the weapon skill damage distribution plot that is generally not enabled. For the Sanguine Blade simulations, I set enemy_meva=0, which tells the code to ignore all resists entirely. Since Sroda Tathlum is being treated as a static 1.025 multiplier, there is no difference in the numbers for min/mean/median/max. Using enemy_meva=1 or higher will start including the small (or large) chance to resist and affect the results.

For physical/hybrid weapon skills, these numbers should agree reasonably well with the "quick look" average as long as you tell it to run a sufficient number of simulations (20,000 - 50,000 ish), but will still differ slightly for multi-peaked distributions (ftp transfer or low ftp WSs with a lot of multi-attack).


Hmm. I'll try to fix this later today. Since the Magian bow/gun do affect melee weapon skills, I think I'll have to brute force it by subtracting 500 TP bonus if Fail-Not or Fomalhaut are equipped and a melee weapon skill is being used.

Thanks. It does seem that using non-zero enemy_meva will reflect resist in the results, but it somewhat differs from what I expected. I was expecting to see some weapon skills being half-resisted, some being 1/4 resisted, and some being 1/8 resisted, so that these are shown in the distribution plot and the minimum number would be 1/2, 1/4, or 1/8 of the maximum depending on the enemy_meva. However, it seems that the result always shows the same minimum, average, medium and maximum.

For example, acting on the defulat Apex Bat, all these numbers are 31373 (in no buff situation); if I add 100 meva to the mob, these numbers together go down slightly and become 30568; as the meva increases they steadily decrease together, until they are floored at 3921, which is roughly 1/8 of 31373.

Is it because you apply a similar arrangement as with Sroda Tathlum, that instead of generating a random number to simulate the actual resits, you somehow translate the chances of resists into an expectation value or something?

Looks like I only use the average resist state, rather than calculating it separately for each simulation like you were expecting. Lines 239 and 264 of nuking.py are the two functions for calculating resist states (one for proper random number simulations and one for a simple average), but I seem to only ever use the average one.

Apparently I put a comment in the proper simulation function on line 245 that suggests it isn't needed for magic simulations since there are only a handful of possible values (rather than a full distribution of values you see in physical melee weapon skills). I believe this was in regards to creating a distribution plot. I should still use that function for simulations, though, but I currently do not. I'll look into swapping it over.

I don't think you understand how simple my method would be and how much more efficient it is. My computer has 4G of RAM. I set the condition to "if True" so every set possible combination and took ~16.6 seconds with other stuff running in the background to go through 1,749,600 sets. I am not sure why you think it would take 45 days to go through every combination. My method wouldn't even check any damage formula until it already met the condition of x DT, or x Subtle Blow, or x any other stat. Here is an example of how it would actually reduce time using some 75 THF stuff I was playing with. I added some formulas for some damage, just for TP, so it did add a few seconds, and I also put on music which took up more RAM.

First output is set to if True, so every combination I could have, from there it makes sure I don't go past 26% Haste, and checks for MA, then maximizes my hit per dagger. I don't have every piece of gear included or something like Strigoi ring would have taken up Alert for example.



If I add the condition to cap accuracy on greater colibri, then my run time actually decreases, since if a set does not meet that condition, then it won't attempt to run it through the Haste cap and damage per dagger formula.


From there, I decided I want to cap subtle blow in addition to accuracy before checking for Haste/DMG



Obviously it would take longer to go through all the various damage checks I didn't included, but this particular method would not run a set through any damage formula without meeting the required gear condition, so it would reduce time, not increase it.

That would be a great change indeed. Especially for things like Seraph Blade and Red Lotus Blade, which have a wider range of distribution like melee weapon skills do, it would be very helpful to see resists being reflected in the distribution plot.

Many thanks for all your work! It's much appreciated.

The misunderstanding between what we're doing has not changed. The scales of our problems are still different.

The first problem is how you build the billions of possible sets so you can even count how much DT or Subtle Blow they have. From what I can tell, you only have 1.7 million sets and it still took 22 seconds to run the basic check. For Ninja, I find over 1.3 billion possible sets that need to be built just so I can check which satisfy the conditions first. That's 4.5 hours just to build the sets on your computer. If I reasonably remove items that probably shouldn't be included, then I can drop this to 46 million sets. It took about 90 seconds to build these 46 million sets using itertools, which is pretty good I think.

I then used list comprehension to reduce these to sets that satisfy 50 Subtle Blow (including Subtle Blow II), -40% MDT, and -40% PDT (including DT). This took an additional 9 minutes and found 288 total sets. I might be able to reduce this to 1 minute or less if I use numba.

At this point, I have 288 base sets that satisfy my conditions and need to have their free slots optimized for damage or DPS. If each set took 1 second to optimize, then it'll still take another 4.8 minutes to return the best conditional set to the user.

In total, this brute force method would easily take over 10 minutes to find the best conditional set with very strict conditions. If I only wanted 20% DT and 50 Subtle Blow, then the 288 sets jump to 581,848 sets, which would require 6.7 days to optimize at 1 second each.

I just don't see a feasible way to do this without iteratively checking conditions like I currently do.

It takes less time to run the conditionals than it does to go through all the damage formulas, if you eliminate those sets, they don't need to be checked through the damage formula, that's why when I set conditions, even though the same amount of sets are checked, considerably less are ran through the actual damage portion, that's why I saved 10 seconds when making sure I cap subtle blow. Out of the 1749600 set combinations I have, only 1862 cap accuracy and subtle blow, so I only have to find the highest damage potential out of those 1862 sets instead.

it's also not necessary to check every piece of gear just because it exists. most people will probably want to lock in a specific mainhand for example.

that's the difference with the method I am suggesting, you don't need to optimize the sets because the sets are already built. the 1749600 sets are already built, that's the total amount of sets I can build, out of those sets, only 1862 met the conditions I had set. and since those sets are already built, you don't need to optimize them or swap gear two pieces at a time, you just check them all using the formulas instead.

so my method built all the sets, ignored the ones that didn't cap subtle blow and hit rate, then out of the remainder, found the one that hit the hardest. and that took 12 seconds compared to 22.

Sorry, I should've mentioned that the numbers I gave above were ignoring the main/sub/ranged/back slots entirely. This is partially why I do not have over a trillion sets like I mentioned in the Ninja thread when this was first discussed. It also reminded me that I did not include "empty" as an option for each slot, so all 288 (or 581,848) final sets found in the previous post were built of pieces that had at least some DT or Subtle Blow in 12/16 gear slots and did not need to be optimized outside of the cape slot. I must leave empty slots in for optimization or we completely reject sets with equipment like Adhemar Jacket and most DD ammos simply because they do not have DT or Subtle Blow.

If I remember to include an "empty" option for each slot so I can optimize it, then I find 1,410,817,408 total Ninja sets to check conditions for. This is 800 times more sets than you have and would take over 2 hours if it takes 10 seconds to check 1.75 million. Just building my sets with itertools would take 45 minutes assuming the problem grows linearly from 90 seconds per 46 million as I saw previously. I did not run itertools for 45 minutes to confirm this, though.

I would really like to use your method, but the scales of our problems are so vastly different that they really can't be compared. Technically I could pre-build these sets, save them as a pickle file, and include that with the code, but that doesn't help with optimizing the potentially hundreds of thousands of sets that satisfy the conditions.

I don't have to have empty slots this way.

The time to run the program was start to finish, it was from when I hit F5 to when it gave me the optimum set. The 22 result second one was the 1.75M, and since I forced it to true, it ran all of those sets through the damage formula. When I required the set to cap accuracy, it took less time since I don't have to run every combination through a formula. Likewise, when I added even more restrictive gear by capping Subtle Blow, it took even less time. It builds every set possible, if the set does not meet the requirement, then it does not get checked for damage since the set won't meet the demands.

I don't have to take "1 second to optimize" since the sets are already completed, and it would check each full set, it doesn't require you to go through, change a few pieces, run the formula, and try again, then double check the work at the end. That is where you will end up saving time.

Shared this with a few LS mates and some more questions / suggestions...

1. Can you add options for JA's from sub jobs, examples such as berserk & warcry for sub war.
2. Regarding SCH storm spells... could you add an option for all casters, even if not sub SCH, to have klimaform with the appropriate weather? Might even be worth adding it to the "Buffs" area, since storms from a SCH with 5/5 storm surge add +7 of the matching stat (firestorm = +7 STR, etc). Was thinking you could have the specific storms as a drop down, and then klimaform as an option like you do for Marcato. This would make it so you don't have to assume the storm2 potency on SCH main and Storm1 potency on all other casters. And it would make it more accurate for other jobs as well who may use Obi's. You could even add a "day" dropdown for the day bonus/penalty as well.
3. You mentioned in the initial post, "Automatic Ranged attack white damage set finder, focusing on damage dealt or TP returned" and I'm struggling to get this to build a ranged TP set for me on COR. May be user error... but I'm setting "Ranged TP priority" to TP>Damage and I also tried TP only and the sets it outputs still seem multi attack focused when clicking "Run TP". I have "Ranged attack" selected on the inputs tab as well. Feel like I might be missing a step?
4. You mentioned Empy and Relic weapon AM procs are already in the logic. I assume that's based on if you have the appropriate weapon equipped it will assume the appropriate AM3?
5. Would it be possible to add a similar option & drop down for melee TP priority as there is for ranged? For example, a Masamune SAM with AM3 up would want to have more attack in their TP set for extra white damage.
5. In the "Quick-look WS" and/or WS charts, could you add what your average TP return would be if you WS in the set specified? I admittedly don't know if that's possible since I don't know all the specifics on how TP return is calculated.

Do you have a similar tool? Would you mind sharing it with me so I can play around with that too?

not exactly, the method i use is mostly for utility sets. PLD for example, a lot of players like to maintain X amount of HP in their sets, so if you want a Fast Cast set that keeps that HP, my tools will find the sets that maintain HP needed and give me the most Fast Cast available.

If you are more interested in a mid cast set, like cure potency, I can require the same HP, capped DT. From there, I can find the set that gives me the most cure, and if multiple sets reach that cure potency, give me the one with the most enmity. I can even require capping SIRD if possible before giving me the most cure.

this can be changed to work for a damage formula instead, though. since the program he made is aiming to find the best sets based on the mean, then the result should be the same every time, so just writing the method I use to use the mean of all the formulas should get the same result.

for my own DPS programs, though, I make full simulations that will perform exactly like playing the game with all the RNG involved. mine do not have GUIs and do not find the "best" gear for you automatically, you have to manually adjust the gear you want to use but it gives me in-game accurate results since I can set it up for any situation that you can do in game if we have known stat values. the only thing i have not added yet is multiple party member skillchains, i currently have support for the jobs I have done that can solo for up to a 4 step.

in simulation situations, i don't use the mean as often. i tend to look at the results between 25th and 75th percentile, since that's where the majority of my results will come from. there are usually outliers in this game, you can for example, over the course of a 5 minute fight and nothing changes in variables a difference of up to 25% between the lowest and highest average DPS value. so i focus on keeping my average similar while improving the 25-75th percentiles.

The method I am suggesting is for a project I am working on mostly for myself as a retrospect of how wrong was our gear at 75 cap.

Would you be willing to share still? The HP amd DT midcast examples you mentioned would be very useful.

Is it possible to have a "Defensive" toggle that would allow sets to consider 3 factors (500+ Meva, 50+ MDB, 50DT) in the main equipment slots (head, body, hands, legs, feet)?

I sent you a PM

1. This is doable, but I don't think the GUI has space for it right now. I'll add subjob ability checkboxes after I find time to rearrange the GUI.

2. I'm not sure this is necessary, but since we have space in the WHM buffs section for a few more drop down menus, I've added a dropdown menu for Storm2 spells. Selecting a Storm2 spell will enable the +25% damage boost from Hachirin-no-Obi and automatically apply +15 Magic Accuracy from Klimaform, which is assumed to be active if you have Storm2. Additionally, each Storm2 selection will provide its corresponding stat buff from Scholar's Stormsurge.

   • Remember to enable WHM buffs if you want to use this new drop down menu.

3. To check Ranged TP sets, you have to unintuitively select "Ranged Attack" from the spell list, then click "Run Magic." This is because ranged sets were one of the most recent things I added and "Run TP" was already built soley for melee TP sets. I have no plans to change this until the GUI gets an overhaul in the far future.

4. Right now, if you have a relic/mythic/empyrean equipped, then it assumes you have aftermath up. Gandiva/Armageddon should only affect ranged attacks while melee Empyreans should only affect melee attacks. I need to set a checkbox to enable/disable aftermath effects.

5. Melee TP sets only support "time to WS" right now. I need to get around to adding contribution from stats like "DA DMG" and "TA DMG" for melee attacks before any "damage" or "dps" metric will be meaningful. This should be an easy addition to the code, but I've been putting it off for a while since I assume it'll require a good bit of testing.

6. The code actually already calculated TP return from WS, I just never used it. I've updated the quicklook display for WSs to show TP return as well.

   • My FFXI subscription ended before I could test it, but I assumed that TP return from multi-hit ranged WSs behave the same as multi-hit melee WSs in that the first hit gains full TP, while the remaining hits gain only +10 TP (before Store TP).

While the code does record and display those four values (meva, mdef, pdt, mdt), I have not found a way to set requirements for all of them together within a reasonable amount of code runtime. I'm looking into memory-efficient methods to handle this, though.

Been using the tool for a while, was wondering if in a future update you could add a preset for the w3 dynamis mobs like the apex you got? I admittedly wasn't sure on all their stats so I just used an apex and changed evasion manually to get close but not sure how important is to be accurate on the stats.

I have no idea what stats they have. If you have an enemy you want added and a list of stats for that enemy, then let me know and I'll add it. Keep in mind that different w3 enemies have different stats.

In terms of how "important" the enemy stats are:

• Evasion is important as it defines exactly how much accuracy the code aims to have. Notice that when you enter high evasion value, the code typically outputs a set that is barely capped accuracy. As far as I can tell, this is the stat that the code prioritizes the most (as it should).

• Defense is not very important as long as you're close to a reasonable value for what you expect to fight. You'll typically only find three different sets: low/mid/high buffs. Low buffs prioritize more attack. Mid buffs start to introduce more WSC, multi-attack, WSD, etc. High buffs throw on some PDL and, if necessary, some extra attack+ to enable the higher PDIF limit. You'll likely be in the mid-buff range, and spend very little or no time in low-buff range.

• Enemy VIT defines your fSTR, which is used in base damage calculations. The sets I posted in the main post use low enemy VIT, which may be considered a mistake since a higher enemy VIT value (as you would likely see in real content) would likely favor equipment with higher STR than what I posted. The differences in the sets for high VIT enemies is likely minor (at the ~1% level, I imagine).

• Enemy AGI defines your crit rate from dDEX or dAGI for melee and ranged attacks, respectively. This only affects critical hit weapon skills (and damage in TP sets I guess), or melee weapon skills with Shining One equipped. Finding sets for crit weapon skills is already pretty iffy. It may be best to assume high enemy AGI so you do not rely on crit rate from dStat.

• I have no idea how to handle Magic Evasion. I keep it at 0 to ignore resists, but it seems that 800~1100 might be a good value to use.

The other few stats are pretty minor (unless you consider dINT for Kaustra).