I would like to suggest a few features going into Endwalker that I believe would help improve FFLogs in some ways or at the very least help to possibly give some ideas.
As a disclaimer :
I have been using FFLogs since the 1st tier of Stormblood and I have seen it improve over time. For me FFLogs adds insane re-playability in Savage and EX trials, I love the competitive aspect of it but also being able to deeply analyse runs in order to improve individually and as a group. I’m hopeful FFLogs can keep on improving and growing as expansions go by.
Obviously some of those features have personal benefits but I also believe they would benefit everyone.
I would also like to point out that feature #2 goes hand in hand with feature #1.  (found in Feature #2)
Feature #1 : Raw DPS, that’s a DPS value that I believe is more accurate of the actual individual performance while not being as exploitable as rDPS and aDPS.
While I do believe adding rDPS and aDPS was a huge improvement going into Shadowbringers and really made it more fun to compete ranking wise.
I also believe those 2 values have flaws which end up essentially creating unfairness based on compositions and based on manipulations that will have huge impacts on individual performances (on top of not being exactly ideal when one is looking to improve individually).
I’ll mostly compare with rDPS as I do find aDPS to be lacking in terms of purpose (it’s only taking party buffs (and not single target buffs) into consideration in order to become an incentive to align buffs and CDs in an optimised manner but that’s, in my opinion, already an implied concept of Speed Kills as they require to maximise the overall group DPS. aDPS is also heavily reliant on composition as a result). Although both rDPS and aDPS share the same flaws.
The 1st thing to mention is the basic elements around a performance (things that affect it) :
- Kill time
- Strategies used
- RNG (the 5% disparity in the damage calculation, the direct hits and the critical hits (as well as the spells on which they occur))
While A can be manipulated, B requires group coordination in most cases and C cannot be controlled.
There is obviously the element that represents the actual individual performance, which is essentially how optimally someone has played the fight (rotation, CD usages, uptime, BiS tweaking and whatnot).
I’m mentioning these because they affect not only rDPS and aDPS but also Raw DPS.
While it’s probably possible to come up with a value that would take the kill time in consideration, we would still be left with B and C.
What are the flaws of rDPS ?
The biggest flaw of rDPS is that it is possible to manipulate things to maximise the damage output inside of a single individual buff windows (as an example you could hold on CDs and such to maximise your DPS inside of all the Trick Attack windows).
Another flaw is also that, like aDPS, rDPS does rely on composition (to a lesser extent but still), having stronger jobs DPS wise or buff wise will create a difference in how much value you can get from buffs (for example having a DNC over MCH/BRD, a SMN/BLM over RDM and such (depending on tuning and tier)).
rDPS (and aDPS) relies on optimising the way buff windows can be aligned alongside burst windows, meaning that it is a group effort rather than an individual one.
To showcase an example of the manipulation of things in order to maximise the rDPS of one individual, I’ll use a real example from the top E5S NIN in the patch 5.2 (with the only intention to showcase how much rDPS can be exploited while also comparing Raw DPS wise).
I’ll use the #3 NIN and compare with the #5 NIN (you would expect both to be close not only rDPS wise but also Raw DPS wise as the ranking should reflect how well people are doing individually) :
Actual damage done inside of Trick Attack windows from the comparison above (I’m using URL parameters rather than queries).
As you can see, while the #5 NIN’s group is doing well and getting a 7:34 kill time, the #3 NIN’s group is seemingly doing pretty poorly. The thing is most members are holding on things to maximise their DPS inside of the TA windows on top of manipulating their DPS to affect the kill time (both DRKs used their AoE combos outside of TA windows and used Bloodspillers strictly in the TA windows, the BLM used Umbral Soul 28 times while using Xenoglossy strictly in the TA windows).
Here is the xivanalysis link of NIN #3’s run as it is easier to look at the timeline of casted spells alongside buff windows.
Additional information concerning #3 NIN’s group members :
Both DRKs are #6 and #1 as GNB on this tier (meaning tier #2) on top of doing really well to extremely well on other tiers and Alex.
The SAM is #10 on this tier.
One of the WHMs is #2 on this tier as a PLD.
They almost all have hundreds of kills on most bosses on this tier.
While this probably looks like an extreme example where really good players did their best to essentially pad someone’s rDPS, it does nonetheless prove that rDPS (and aDPS as well) is exploitable (Although to a lesser extent compared to how the normal DPS value was in Stormblood).
My point is that I believe better can be done, which is where Raw DPS comes into place. Obviously this is a simple suggestion/analysis of things, while I’m not necessarily expecting the implementation of it as is, I do hope that this can be of help in any way to eventually improve existing systems to at least reduce the level of exploitability.
What is Raw DPS ?
Raw DPS actually already exists in the case of the following jobs (pre-EW) : SAM, BLM, MCH, WHM and all 4 tanks.
When rDPS is calculated for these jobs, they essentially have 0 when it comes to both contribution and given, only leaving them with their own self optimisation (although I’m unsure how the DPS gain is calculated from aligning a self buff with buffs, if it’s added to the “taken” or if it’s simply not shown, meaning added to the DPS (I’m talking about the gain you get from both 1) the same buffs multiplying each others like % DMG with % DMG and 2) getting a crit or dh proc thanks to a buff while having a self buff)).
Now based on the 2 examples above, the Raw DPS would look like this :
- NIN #3 rDPS is 20 128.4 while TA gave 2292.7
- NIN #5 rDPS is 19 943.9 while TA gave 1664.6 (showcasing a huge difference between TAs)
To get the Raw DPS, we just need to take the rDPS value and subtract the “given” value from it (meaning the TA in this case), becoming as follow :
- NIN #3 Raw DPS is 17 835.7
- NIN #5 Raw DPS is 18 279.3 (now showcasing a significant difference in terms of Raw DPS)
I’ll add the #1 NIN E5S 5.2
- NIN #1 Raw DPS is 20 406.4 - 2092.8 = 18 313.6
To draw one last comparison I took the lowest 99% NIN as shown in Rank % based on patch 5.2, which is NIN #119 E5S 5.2
- NIN #119 Raw DPS is 19 169.2 - 1679.7 = 17 489.5
NIN #119 is 346.2 Raw DPS below NIN #3, actually a smaller gap than the gap between #3 and #5 while going as far as #119 (while the rDPS gap is 959.2 between #3 and #119).
This I believe showcases the individual performances, exposing the fact that NIN #3 (and their group) in this case evidently exploited the flaws of rDPS while the difference between #5 and #1 is only 34.3 Raw DPS, which can come from the basic elements A, B and C as stated above but also from potential self optimisation.
Of course Raw DPS has flaws, like rDPS it does also have the kill time manipulation and although it doesn’t have the flaw in which you can manipulate others rotations and CD usages and such as buffs given won’t be taken into consideration, depending on how FFLogs calculates the gain from aligning buffs with self buffs, there could be the flaw that aligning buffs with self buffs would essentially do nothing, meaning there would be a lack of coordination necessary (although that is still a thing with Speed Kills or in order to get a better kill time) while the opposite would be a flaw as well as that would mean aligning still has value which could imply that composition matters (although to a much lesser extent).
One last thing to mention is when trying to improve oneself, Raw DPS is much better for that as it is easier to monitor from run to run compared to rDPS (and aDPS) since buffs render any potential gain or loss inaccurate.
Feature #2 : Composition Based Speed Kills
Essentially, as of the current system, the Speed Kill Ranking only takes into account the clear time.
I believe this creates a situation where this heavily pushes for meta compositions, as shown on the Speed Kills Ranking pages by the % representations of jobs. Meaning specific jobs will be BiS in terms of composition slots, which leads to very little variations in the compositions that manage to get the shortest kill times.
My suggestion here is having 2 rankings in Speed Kills :
- Overall (aka current ranking)
- Composition based
I’m sure there are different ways to implement this and the developers could find the most elegant solution for this.
Composition based ranking means giving the possibility to any static to compete speed skill wise independent of their composition.
 : It also creates this situation where on one hand we have Raw DPS where people can improve and compete on the individual level and on the other hand we have Speed Kills where people improve and compete as a group (in which case optimising the alignments of buff windows and burst windows allows groups to shorten their kill time).
Now, I believe there are 2 scenarios in which the Composition Based Ranking will have to be either processed or retrieved (whether it’s the value or the actual list of groups matching a specific composition. Depending on design and implementation as well).
As a note, the “Speed” tab found on a given tier could now have 2 sub choices (Overall and Composition Based). To avoid unnecessary loading of data from the server, the default “Speed” page could simply allow to pick between either (it would make sure users don’t load the Overall Speed Kills list in the cases where they simply went on the Ranking page of a given boss or tier when they wanted to look at other tabs).
- A user wishing to look at the Composition Based list of Speed Kills
- Here I believe initially no data should be loaded by default
- The main feature of this page would consist of being able to pick a given job for each slot of a composition. While you could simply pick any possible job for each slot, you could also split slots into roles (2 slots for Tanks, 2 slots for Healers, 4 slots for DPS) where each slot only gives the corresponding choices (this would help create clarity and ease of use for the user while being specific rather than generic in which case you couldn’t retrieve a list for non-standard comps for example)
- Whether or not the user can load the list based on a composition without filling all 8 slots is a matter of design (example : GNB DRK AST SCH SAM X BRD X where the list would load any composition matching the jobs picked, essentially having to fill the free slots while also avoiding duplicates) but also a matter of ease of implementation
- A user uploads a run
- Here essentially, when a run is uploaded, different pieces of data will be processed in order to be able to show things like individual rankings and such. In this case the new thing from composition based would be to, on top of showing the Overall Speed ranking, also show the Composition Speed ranking
- Again, depending on design and implementation, data will be processed in a specific way before being able to retrieve the actual ranking for Composition Based (% and actual rank)
While I perfectly understand the difficulties behind implementing this feature (since you can’t simply manipulate data without properly implementing a design solution as it would conflict with, for example, the data retrieving aspect where you need to be able to load data block by block (paging). But also with other things (or simply because it isn’t elegant nor open to possible expansions around the feature itself)).
I do believe however that this would help create a proper competition on the Speed Kill side of things.
The following features (#3 and #4) could probably be seen more as simple changes/ideas as they involve existing features.
Feature #3 : Best Today % (instead of “Best %”) on players profiles when looking at given raid tiers or trials
Currently when looking at a specific player’s overall raid tiers or trials, we can see a value called “Best %”, this value is essentially “Best History %” but its name is Best % which is ambiguous as I believe a lot of people misinterpret it, so if they see someone with a Best % of 100 on some bosses, they’ll interpret this as a legit 100 without realising that 100 might have been a very early clear and now (when everyone is full BiS and got the chance to parse) could actually be something as low as 80.
My suggestion would be to show the Best Today % value instead of Best History % as the Today value has much more weight to it on top of being much easier for people to process. The reason why is because it’s much easier to know how far into the tier we are as of today rather than back when that run happened (History) which also means anyone would know at that time if people are full BiS and competing or if everyone is still in the process of gearing up.
One last thing to mention is the way some users can behave based on the ignorance from how they interpret this value. Impacting how some people judge other players FFLogs based on this first glance (some never going further than this) or the way some players will be satisfied from getting a high Best History % without feeling the need to actually improve or do better (essentially creating a disincentive to improve in the case of someone getting a History % much higher than any Today % they could possibly get with their current form).
Feature #4 : History % being updated in weekly windows rather than in 24 hours windows
I believe updating the History % weekly rather than daily simply makes more sense as it allows to reach a certain number of parses in the following cases :
- Newly released tier
- Newly released major patch
- As well as any special partition (time split) for a given tier or trial (in cases like jobs nerfs/reworks and such)
It also allows players to get an accurate History % independent of when they clear during a given week (with the downside that their History % may be lowered due to the fact that it would be processed weekly, although that’s not really a bad thing in most cases).
Thank you to anyone reading thus far. I know that was a lot to read and I hope this can be of use for the FFLogs developers, whether as actual features or as ideas for features they already had in mind.