Nate changed the wiki quite a bit, every class now has its own page which lead to much more detail in the ouput itself.
SampleOutputT9Druid - simulationcraft - Project Hosting on Google Code
SampleOutputT8Druid - simulationcraft - Project Hosting on Google Code
SampleOutputPTRDruid - simulationcraft - Project Hosting on Google Code

And lately I'm working on the whole DK module because all the devs working on it until now seem to quit after a few weeks.
I'll have a look into the feral dps thread and commit changes found for better profiles

I also updated the first post for the new expressions system

I have a soft-spot on my heart for the Boomkins so I pushed the next release early......

The latest PTR change is implemented in v13 currently available for download.

Combo points don't seem to be working in the new buff system for ferals like the examples in the first post. Instead, I get an error saying the buff isn't recognized.

I'm adding a note on simc 'lag' mechanics, since Moonkin results are very sensitive to this (and they aren't discussed in the first post). An important default changed this week.

My understanding of this is that simc has three lags it can use. The are (shown with default numbers, in seconds):

queue_lag=0.075
gcd_lag=0.150
channel_lag=0.250

There are also standard deviations used (lag is not a constant in simc), named queue_lag_stddev, etc. These default to 25% of their corresponding _lag values.

channel_lag is used for channeled spells. simc doesn't model any channeled druid spells, so you can ignore it.

queue_lag is used if the previous (just completed) spell had a cast time.
gcd_lag is used if the previous spell was instant.

There is an option, strict_gcd_queue=1. Prior to 30 Nov 2009, it defaulted to zero. When this option is on (the new default), the time between casts is always at least gcd+gcd_lag. When the option is off, chain casting of Wrath takes gcd+queue_lag.

There is another parameter:

queue_gcd_reduction=0.075

If I understand it correctly, your gcd (for casting the current spell) will be reduced by this amount if your previous spell was queued (meaning that your previous cast got to use queue_lag, rather than gcd_lag).

For a sequence like (S represents SF, X represents anything else)

X1 X2 S1 S2 S3 X3 X4 X5

With current defaults the effective lag before casting each spell is

X2 = .15 (gcd_lag)
S1 = .15 (gcd_lag)
S2 = .075 (queue_lag)
S3 = .075 (queue_lag)
X3 = .075 (queue_lag)
X4 = .075 (gcd_lag - queue_gcd_reduction)
X5 = .15 (gcd_lag)

I don't know if simc has any additional penalty for ground-targeted spells (Force of Nature). In my opinion, ground targeting always costs me at least 0.3s, unless the previous spell was channeled.

I personally believe that your effective lag gets worse when the gcd drops to 1s. You can get some effective queueing after an instant-cast (or wrath), as long as the gcd > 1s. When the gcd is 1s (as is frequently the case for Moonkin) your effective lag increases. I'd like to see a parameter that could keep the effective minimum gcd above 1s.

For non-channeled spells, the player becomes ready at

MAX( cast_time + queue_lag, gcd + gcd_lag )

Is gcd_lag not enough to play with?

The problem is, that talented Wrath will always end up using gcd+gcd_lag, because cast_time is always <= gcd.

Skjaven's numbers indicated that lag was higher with a gcd of 1000ms, than when he had a gcd of 1183 ms.

On the other hand, his two lag numbers were 80ms and 108ms. If I plugged a number like 94ms into simc, I'd never be more than 14ms off, and frankly, any guess I make for average latency is likely to be off by a lot more than 14ms.

I'm having some trouble with the new operators. I'm trying to implement a line something like this:

actions+=/savage_roar,if=buff.savage_roar.remains-dot.rip.remains<=4

This is so that we can deal with SR and Rip collisions more elegantly.

You should just write down at what exact conditions you want to cast SR and work from there.
You example:
Rip just applied, 16s left
Shred, 16-1+2=17s left
So you'd cast SR if it has below 21s left on the buff (20s after the shred gcd)

I can just help you in general with expressions, if you tell me exactly what you want to achieve. As I'm moonkin myself, I always copy feral actionslist where someone managed to squeeze a bit more dps.

My problem is syntactical, not theoretical. The above line fails when I try to run the simulation.

The full line might look something like:

actions+=/savage_roar,if=buff.savage_roar.remains-dot.rip.remains<=4&(buff.savage_roar.remains<buff.combo_points.stack*5-5)

As it is, since the first line doesn't work, I can't build a full expression-- am I using elements that can't subtract from each other, or am I getting something else syntactically wrong? Does the "-" operator work?

This has been fixed in r4117.

I was not properly distinguishing between unary/binary operators +/- when used with "functions" such as buff.* etc.

Simple numeric testing, FTL. And of course, I -just- put out a new release. Argh.