It´s not but it´s off GCD and as such not part of the rotation. Just wait until you´ve got 5 frenzy stacks and use it.

I'm using your addon and loving it; very helpful while trying to become accustomed to the new mechanic. I don't have a scientific approach to offer here, but I wanted to bring up a couple things I've noted during my training dummy time (specced MM).

First, it seems the addon is suggesting a lot more single SS than I expected. I would have thought SS would almost always be used in paris.

Second, my sense of my focus reservoir is that it is too high on average (perhaps because of too many SS?). Again, not being scientific, but I would have thought that I'd be getting the most bang for my buck if my focus is generally less than 50%, and perhaps even hovering around 22-24 unless I'm nearing a CS.

I'm also seeing SS be my highest damage producing shot, greater than AS, Auto, and WQ.

At the same time, if I try to substitute AS for suggested SS, my focus remains fine but my DPS seems to drop.

I'm wearing my usual raid gear, cat as a pet, not using RF or anything other than whatever procs on its own.

Not complaining here in any way, just throwing out anecdotes for informational use.

I´m aware of the problems with MM and ISS uptime. I´m still struggleing for a general, codable solution to this problem. Unfortunatly the last few days I couldn´t put much work into improving this behavior because I was busy fixing more important and addon breaking bugs.

I think the reason you feel your focus reservoir is too high is that currently FS takes a minimum guaranteed focus regeneration approach when calculating how much focus you need to have so CS (or any other signature shot) is castable on CD. In other words it´d calculate how much focus you regenerate until CS is ready again, subtract that value from CS's focus costs and try to keep you at or above that level at all times. For this specific check it does account for haste improved regeneration, it doesn´t account for SS generated focus though. So in general it´ll keep you quite a bit higher than necessary. This shouldn´t actually be a problem though if there´s enough wiggle room in between your lower and upper threasholds. If this proves to be a problem I´ll have to find a way to predict how many SS/CoS you´ll do before your next signature shot and include the regenerated focus in the calculation.

This may not be necessary though. If I want to have a 100% ISS uptime* while still doing CS on CD and Blizzard doesn´t change the buff duration I know that I´ll always have to do at least two pairs of SS between two CS. I think I can just hardcode this into FS. I could make FS monitor the remaining ISS buff duration and force two SS if either a) ISS runs out before CS comes off CD and it´d run out before I could start my second SS if I cast anything else now or b) it´d run out after CS comes off CD but it´d run out before I could cast my second SS after CS.

* Actually saying 100% uptime is not the whole truth. It is my understanding that it´s enough to start casting your second SS while ISS is up so you get the short casttime. If you loose ISS while casting the second one it may only have a very minor impact on your focus regeneration and/or next auto shot.

You may want to check out what Rivkah's FemaleDwarf implemention is for his ISS behavior option "steady shot in pairs if ISS has <= 4 sec left".

This works out really well. With my characters stats, it currently maintains almost 100% ISS uptime, with only some small 1 shot drop offs during the KS phase due to CS priority over SS pairs. But that is with firing CS off CD and can be fixed by delaying the CS cast to after the SSs but before SrS falls off.

With that implementation, during 5 mins, 89 SSs are cast. These were cast in 37 pairs, 4 triplets, and 3 single casts. That is pretty darn good.

So how does it decide when to cast the first pair? Also I assume this might push CS back a bit in favor of keeping ISS up? From what I can tell so far it´s propably the better strategy to priorize ISS uptime over CS anyway.

There's no special logic on deciding when to cast the first pair, I just follow the standard shot priority (which means the initial ISS may come up a bit late). The only thing this particular setting allows you to do is control whether the first steady shot turns into two, so that you don't waste a pair once you've already cast one. The theory is that generally if you need to cast one steady, unless you've just cast a pair it's more efficient to just do two then so your ISS is refreshed. The other thing with this approach is that at worst higher priority shots are never delayed more than one steady shot cast.

I have a second option on the site which allows you to prioritize steady shot above all other shots if your ISS has <= 3 sec left on it. That results in slightly higher ISS uptime but the difference isn't large, and it will force higher value shots like chimera to be delayed more often, especially at the start of the fight. Starting a fight with 2 steadies seems like a waste of focus though, so I'm not sure I like that approach. You probably could add a contingency for if focus was above a certain level though to get around this issue.

It can push back the CS a little bit, but currently that is definitely not a problem considering the relative damage of CS to SS and the benefit of the ISS buff. But that is not a big deal since currently, I prefer to still delay my CS cast to somewhere within the last 4s before SrS drops depending on when is convienent.

Of the 39 CS casts in the simualtion for my character with the <= 4s setting:
- 1 was the initial cast
- 2 were cast after Readiness (which is debatable on whether that is currently the best use of focus)
- The other 36 broke down into delays of:

0.00-0.25: 2
0.25-0.50: 4
0.50-0.75: 0
0.75-1.00: 6
1.00-1.25: 7
1.25-1.50: 3
>1.50: 4

As can be seen most of the delays where under the time of a SS cast. Of the 4 that were greater than 1.5s delays in CS cast time, the SS pair started a little late due to focus issues where the sim was trying to prevent an overcap by firing an extra ArS. In 3 of those 4, the ISS buff actually ran out during the cast of the second SS in the pair. Although those results are not ideal, its not bad for a simple rule sim with sometimes competing rules.

One suggestion for the shot display:

It would be a lot easier to use if the transition from shot to shot on the display were more easily readable. Example -- the addon wants to communicate that you should SS 4 times in a row. During these 4 shots, there really isn't any movement on the two icons. You see the SS icon for all of them.

Maybe something as simple as a number in the corner or even the middle of the button would help. I would suggest something like numbers 1-5. So the first 5 suggested shots get the corresponding number, the 6th suggested shot gets the number 1 and so on and so on. Why 5? Well...sometimes the shot priority changes before you actually cast the suggested shot, for instance. Also, because if the suggested shot is a huge string of Arcane shots (during rapid fire, for instance) then it will be easier to see that you are casting them without seeing something ridiculous like oscillating 1's and 2's.

Just a suggestion that I think would add to the usability of the addon.

I don´t understand your question? What proc stacks should I wait for before suggesting CS?

I´m planning on allowing the option to have the frames animated again as soon as I´m happy with the suggestion in general. Those animations should illustrate the transitions much more clearly.

I guess I was thinking of Beserker, but if you are using that for PvE, I guess there is more trouble in what you are doing than waiting for CS. Plus, I forgot that CS is no good anymore, it's hard to get over.

That´s the new spell "queue". The client allows you to queue a new spell before the current one has actually finished. If you cast a steady shot and queue the next one just before it´s finished casting FS moves on to the next suggestion and you should be fine with that.
However unfortunatly FS has no (precise) way of telling if the queuing worked or not until it gets a response by the server so it always assumes it did and just reverts back to the original state if it realizes that it didn´t work.