How SS is calculated and works

[Daemius]

Is there a resource yet for listing SS tiers for each class? Concerned I may be wasting points on black mage in spellspeed. My old strat was just to stack as much as possible while maintaining accuracy caps.

[Krindor]

Is there a resource yet for listing SS tiers for each class? Concerned I may be wasting points on black mage in spellspeed. My old strat was just to stack as much as possible while maintaining accuracy caps.

Currently it's actually quite close to impossible to creat a tiered list for BLM, it's simple for most classes but when it comes to BLM, most of their attacks have different cast times and each individual cast time as well as the cast time has their own tiers making creating a specific tier almost impossible, I would say for BLM it isn't too much of a worry and you should just keep on stacking SS.

[Krindor]

snip

After a significant amount of testing performed by both me and Dervy we've both seen the effect and it's impossible for it to not be tiered. No matter what tests we did, there was basically no difference between the first 25-26 points but as soon as that extra point was added the speed would be dropped by close to 0.01, this is too large of an effect to simply be something of a chancec. I noticed this about half a year ago when doing some tests, but at the time I thought it was just by chance, now that both me and Dervy have done extensive testing it shows that it's definitely a thing. Also as mentioned by CookieMonsta this is also something that is understandable due to its effect on the servers. Even if it was dropped from 0.01 to 0.001 it wouldn't be able to account for every single point of stats,

[SunnyHirose]

Okay, fought a headache long enough to take at least one look at it, sorry to hold back on ya brah

One thing about your empirically measured tiers I've noticed is that they closely correspond to the timing of "frames" (this makes a lot of sense if you understand a little about graphics programming / game development; it is possible but unusual to handle input at higher frequency than your display refresh rate, so obviously they're not keeping a running tally of how much frames have robbed us, but are instead rounding each time).

That is, you have:
354-360 at 2.511–2.513 → 151/60 = 2.517,
361-386 at 2.497–2.501 → 150/60 = 2.500,
387-439 at 2.482–2.485 → 149/60 = 2.483,
440-492 at 2.461–2.467 → 148/60 = 2.467,

and so forth. Two layers of rounding, yech!

[Krindor]

snip

Correct me if I'm understanding this wrong, a tad tired right now. But if I'm not wrong what I can gather from this is that you mean that either the system only calculates this based on the refresh rate, which I guess is set to 60 for all meaning that the tiering is even larger than what the tooltip shows. Or that due to being limited to a refresh rate of 60 we can only get data at these points. But with this rounding, I wonder if it isn't almost heavier calculations than just simply rounding once.

[SunnyHirose]

There is more than one possible explanation, but the the simplest hypothesis is that the engine waits till the first frame the skill is "off cooldown" to register the next GCD instead of prorating fractional time. So in that case, the rounding as a computation would only be once (and probably down, since that's just how this game rolls), but there would be effectively a second rounding enforced by the engine not rewinding time.

Lots of games (I'd conjecture the vast majority, considering how many games are for old-school hardware where this was the only way you could really do it) tie input registration to displayed frames; although I know such things because I've been an amateur game programmer most of my life, this can be observed if you play games on a potato like I do and have to wrestle through a few slideshows now and then.

If you lock FPS lower (higher!?) and observe the tiering changing accordingly, then I'd dare say this is the most probable explanation.

[Krindor]

snip

I usually run the game on a 60hz monitor but I can test it out at 120hz and see if it changes anything.

Though while I see the reason to do it, it still seems weird that they would implement such a system and then hide it by using a missinforming tooltip. Also from my very limited experience as a programmer(Basic image enhancing and recognition) counting 100 times per second and then display it when needed shouldn't be taxing at all. Tbh I'm feeling that this is caused because of the programmers being behind the western, modern standard.

Also do you have any theory as to why the stats shown by the tooltip is using really weird patterns instead of the logical 26/27 or 66 and instead like 8 sec for example which does it as something like 7,6,7,13. Still fits the 66=1% but in a bursts instead of a regular flow.

[Judge_Xero]

Interesting about the frame rates. I tested @ 84hz but I also have my graphics on Standard for a constant 100 + FPS otherwise the game feels sluggish.

Testing just a 2.5s GCD I've had swings in the range of 2.455-2.536 which average out in the area of 2.506 (I estimate with enough data entries this would come out to 2.45-2.55)

So would that mean I have 4 frame swing? (4/84 = 0.047s)

If one attack comes out @ 80th frame the next is pushed to the 88th frame and so on.

Then if I was running 60 fps is should be in the range of 0.0667

30 FPS = 0.133 range?

Or will this be a straight up loss with lower hz?

------------------------------------------

Edited:

Just wanted to mention too that while testing,

because I wanted my skills to go off as accurately as possible I first started by mashing my skill button as rapidly as possible hoping to get the GCD timing as tight as possible. Using that method actually created inconsistencies because if a skill was selected @ the point of being queued and then I mashed the action again as the GCD finished it would cause a delay due to thinking another skill was selected.

All the data I've posted has been of values where I only did a single click for a skill queued as it proved imo more accurate.

[Waliel]

My wild guess would be that the servers are running at "60 fps" and that's their tick rate for handling skill usage.

[SunnyHirose]

Though while I see the reason to do it, it still seems weird that they would implement such a system and then hide it by using a missinforming tooltip.

Well, I'm very much in the line of game design thinking where uninformed decisions are Not Fun. But I don't think SE means for this particular system to deceive anyone; it is likely they haven't been able to give this issue quite as much thought as the most dedicated of theorycrafters, and complicating the program to make a difference that can't really be noticed except by someone measuring carefully is a hard sell as a good use of development time.

Now, I have a tendency to ramble on, so I'm really trying not to make this post into Sunny's Heterodox School of Game Design (trust me, the first day of classes alone gets people angry), but it's gonna get close here.

Also from my very limited experience as a programmer(Basic image enhancing and recognition) counting 100 times per second and then display it when needed shouldn't be taxing at all.

For starters, there isn't really such a thing as "display it when needed" in modern graphics or game engines. But suffice it to say that if "frames per second" means anything in your system of graphics, you can't. Maybe a proper answer is a lot more complicated than this, but fundamentally, you're queuing up frames so that they show up in a coherent way and within a reliable time period.

I put it this way because it's analogous to how most systems in game engines are architected. Rather than taking every possible thing as it comes, it is far more efficient in terms of memory access patterns and rules of the game's logic for separate engine systems to run at a certain rate (independent yet in concert with other systems) and process its jobs on its own.

Your view of performance seems to be that it should be proportional to CPU processing speed? It's intuitive and it's true if things are loaded in (a very very small portion of) memory, but this view is increasingly discouraged in modern times. Memory access is just so much slower than CPU processing, and the problem has only gotten worse over the years. It affects issues like why load times are still a thing in games even though the hardware is so much better, it's at least two of the reasons why "globals are bad" in programming--and it's at this point I'm going to cut myself off instead of going overly technical but I hope you get the picture: games do things in batches for performance reasons, because they're trying to do millions of different things; but computers run fastest when you do millions of the same thing. Therefore, there must be compromises and shortcuts. You are looking at exactly such a situation here.

Now they could, for trivial processing time, add or subtract time to GCDs in order to match a theoretical time, but changing time components adds complexity to the game logic and may have unintended side effects, so it's not necessarily as trivial as it may sound. And it already appears as though they wanted to make the simplest possible implementation of input on their end, so take that as you will....

Also do you have any theory as to why the stats shown by the tooltip is using really weird patterns instead of the logical 26/27 or 66 and instead like 8 sec for example which does it as something like 7,6,7,13. Still fits the 66=1% but in a bursts instead of a regular flow.

Sorry, I never managed to piece that together, or else this thread might've existed many months ago. I started looking into it shortly after figuring out the crit coefficients, but didn't get anywhere. Plus, the point by point testing is not a task I relish....

Or will this be a straight up loss with lower hz?

If my hypothesis is correct and the same method as the OP is used, I think that's what'll happen, yeah.