I've finished updating the BG Wiki pages to include +4 AF/Relic gear. All gear sets should also show damage dealt by the set against the test enemy. Click the "Expand" buttons to check the TP values used for each set.
I've added a few more sets to certain job pages, such as
the MNK page now showing with/without impetus/footwork for some weapon skills, and
the RNG page showing AM3 and Barrage sets (which are
very strong if the math is correct).
Let me know if I've missed something important.
I added Stinger Helm +1 R15, but I'm not seeing the usefulness of this item outside hyperbuffed situations where you don't need accuracy or attack.
Sorry if I missed it, but is there any way to calculate SC damage (or put in parameters for specific SC to occur continously)?
Yes and no. This feature exists for DPS simulations in an older version of my unpublished test code, but it is limited to 2-step skillchains. I wanted to allow up to 5-steps, but I ended up getting busy before finishing it.
I've updated the sets for NIN
Much respect for your work. Mind explaining why AGI Andartia's is listed in several of your sets? What am I missing here, ranged acc/crit rate?
I was wondering as well but then my assumption was that it was for the little bit of ranged acc+ it would give and that was bridging the gap on locus/trash mobs. DEX was likely just overkill from an acc perspective I imagine and it spits out AGL for the above reason.
This is my understanding of it as well.
The code adds +100 Ranged Accuracy for Daken by default, but that alone isn't enough to cap ranged hit rate against enemies with 1350 evasion (the test enemy for BG Wiki sets) when some of the best head/body/hands/legs/feet slots provide zero ranged accuracy bonuses (Mpaca/Tatenashi). The code finds that the ambuscade cape and Path C Adhemar are the best places to gain ranged accuracy without sacrificing too much else.
I use "AGI+20, DEX+10, Store TP+10, Acc/Atk+20" on my main NIN TP cape as a middle-ground. I lose 20 DEX (~15 accuracy and some dDEX crit rate), but gain +20 AGI (~15 ranged accuracy, ~10 evasion, and some dAGI subtle blow).
I have not looked into this in a long time, but I believe that I can safely say that this is almost certainly not an "easy" fix and it will not be implemented for a long time (if ever), unless I've missed a simple way to do it while investigating this exact feature long before the GUI was published. This is also currently one of the main reasons I've never removed the "beta" from the project name despite hiding the original project repository on GitHub. If I ever find time to learn how to properly write a GUI, this is something I'd definitely want to do.
Python is not a GUI-friendly language. TKinter GUI elements are built on a grid system, with all elements assigned a fixed column and row value. The way TKinter is built requires that the row/column positions remain fixed relative to each other, but their content can stretch/shrink to match the resized window. I've explored this as an option, but it doesn't always behave well or even look good. Your suggestion requires rewriting the entire GUI from scratch and implementing dynamic positions for all GUI elements based on the window size. I'm not even sure if this is technically possible with Tkinter.
In your example image, moving the equipment selection from the bottom of a vertical GUI to the right of a horizontal GUI requires moving the frame holding the equipment selection subframes from position "row=2, col=0" to position "row=0, col=1" and rescaling everything else to not break format. The GUI still has a hidden "self.horizontal = False" flag to enable exactly that, but it looks like enabling it no longer works after all of the changes to the code since it was implemented. "Fixing" this would also mean maintaining two separate versions of the GUI code (~6400 lines of bad code at the moment), which I want to avoid doing.
Similarly, scrollbars are a huge pain in general since everything about them must be pre-defined manually. The GUI already has at least one issue with scrollbars that you may or may not have noticed:
For now, I'll simply copy/paste my response here to GitHub for completeness. But I do not see myself closing that issue unless I have a burst of inspiration. Maybe AI could handle it if given the mess of the GUI code as is?