FCFS (Retribution) modeling script
 

Following some discussion of late in the Ret Paladin thread, I decided that I was interested enough in the philosophical problem of prioritizing FCFS rotations that I would take a crack at some scripting to model different scenarios for Retribution FCFS rotations. The purpose of this script is not to provide another DPS calculator for Ret paladins, but rather to serve as a validation tool for Exemplar, Redcape, and anyone else who is trying to develop an FCFS priority system. The script runs a simulation which can be used to verify or disprove various assumptions about FCFS. However, I have no intention of developing it into a full-featured, user-friendly program. (If someone else wants to take it and do that, more power to them.)

Currently posted is version 2 of the script.

The script is written in Python, and can be edited and executed relatively easily by downloading and installing the free Python development environment. (I don't really know much of the innards of Python; I'm just using it because it is very easy to script in and because I used it last summer for some rogue theorycraft work regarding poison application.)

Basically, what the script does is use some user-defined values to simulate a basic FCFS rotation over a period of time. So far, what I have is a hard-coded priority list with no delay logic built in. To change the FCFS priority, you have to edit the code of the script. Latency is now incorporated as well as damage estimatation. The FCFS priority is still hardcoded.

Retribution FCFS Simulation Script v002:
Changelog
v001

• Created script

v002

• Added latency modeling via increased GCD and other cooldowns, as per Exemplar's suggestion
• Added Divine Plea and the capability to reseal
• Added a crude damage estimator
• Improved usage interval calculations as per Dokb's suggestion
• Hard coded resealing-specific priority into the FCFS system
• Hard coded an optional delay-to-judge option in the FCFS system (uncomment code to enable)

Sample Output:

• 30 second runtime
• J > CS > Cons > DS > Exo > HW
• Undead/demon target = TRUE
• Hammer of Wrath not used
• 4pT7 = TRUE
• Consecrate Glyph = TRUE

Average interval problem went away in v002 due to a new way to calculate it.

I'll post some runtime results from v002 further down in the thread.

Please feel free to take and modify this code as needed, or to request specific setups to be run, etc. Please post bug reports, etc, to this thread. If I get some time, I'll try to refine the modeling in a useful way, but since this is currently my lunch break project at work it won't necessarily happen very fast.

Note that you may also be interested in Zengir's work, as he has put together a similar program in .NET which more fully supports rotations and priority systems. At the time of this writing, this post links to his latest version.

Average usage interval
 

Regarding the average usage interval, I see a simple way to estimate it.

You'd have to record the first time an ability is used and the last time it is used. Then you would calculate : (timeLastUsed - timeFirstUsed)/(numberUsed-1). The -1 is to prevent what is happening right now, since you will always end up calculating the average use on a time period where the last ability used is the one concerned.

To do so in your script, you would have to add two variables per ability. One for the timeFirstUsed, and one to inform the script if the ability has been used.

For example, if you want to do it for J, you could add in variables :

Then when you simulate the J priority :

The simulated average usage interval would then be in the script :
By the way, I have never coded anything in python, I might be wrong with how I write the code, but the idea behind is quite clear I believe.

That's an excellent idea. Thanks for pointing it out. After seeing your code (and yes, Python really is that simple; it's why I like it) I think I'd modify it as follows:

numJ provides a natural tracking parameter.

I don't have time to do this now, but I'll see if I can fix it for later.

That hardly seems necessary. Running the script with length = 6 hours takes less than two seconds on my (not terribly powerful) computer, and that dwarfs the end-point errors (which are all plus or minus 2, maximum).

I have altered a segment of the code to allow it to avoid CS immediately after Judgement (as some prefer):

Behavior is controlled by the dontCSafterJ variable - if it's True, CS is given much lower priority if Judgement was the previous ability.

Some interesting conclusions from using that variable:

1) If Exorcism isn't being used, noCSafterJ increases the number of Judgements used by a few percent, because the partial cds line up better.
2) If Exorcism IS being used, noCSafterJ decreases both CS use and Judgement use.
(With No Exorcism, Consecrate is up 100% of the time if noCSafterJ is activated, by happenstance of gcd timing).

I will leave net numeric conclusions for when I have more time, but here are ability counts for the four cases for a 24-hour long fight:

1) Exo:
2) Exo, noCSafterJ:
3) No Exo:
4) No Exo, NoCSafterJ:

Edit: Something seems wrong with those number, I'm checking into it >.<
Edit again: Nope, they're fine.

The thing that had me worried was how the judgement count matches up with the cs count on every run. That actually is what should be happening though - we lose a 192 each of DS and Cons for 287 each of Judgement and CS. Seems like a good trade to me.

Might be worthwhile to make the loop occasionally skip chunks of gcds (out of range, mechanics of a fight type thing), and see how well the 'noCSafterJ' concept copes with rotation interruptions.. I'll get something on that later.

No Exo, noCSafterJ repeats after 21 seconds, with J>CS>Cons>DS (as I believe is common knowledge now in the main ret thread):

Off the cuff idea:
You should be able to get a rough approximation of latency by adding a latency variable. Add this variable to cooldown time of all abilities and to the GCD used to cast abilities.

If you want to model Divine Plea and Re-seal, this would be easy. Just give DP a 60 sec cooldown, Seal about a 90 sec (so it starts looking early, but not too early). Then set them to only cast if nothing is under a whole GCD remaining on its cooldown.

To include latency you could just model it by a fraction of the step.

Say you have 200 ms latency, when you judge, it occurs 200ms later or 2 step later.

You could write it like this (using the judge portion) :
latency would be between 0 and whatever. It has to be an integer so that you don't mess up your step. If you need a smaller latency, you'd have to use a smaller step.

Hi!

I've been fiddling around with different rotations for a while, and trying to make the best of it with excel-sheets and such, but I got tired of having to type it all in everytime, so I made a simple application for it in C# .NET.

You enter your average damage on JoM, CS, DS, Consecration, melee and SoM, weapon speed, the length of the fight AND your preferred rotation AND your cooldowns on your spells (allowing for 10/8 sec consecration and 7/8 sec judgement)

The output looks like this with very simple numbers, JoM: 7000, CS: 3000, DS: 4500, Cons: 5000, Melee: 3000, SoM: 1000, 3.0 weapon speed (after haste) and fight length 240 seconds:

--------------------------------------
Simulation time: 240 seconds.
Judgement cooldown: 8 seconds.
Priority: jom > cs > ds > cons
Total DPS: 3741,67

Number of casts:
JoM: 29
CS: 36
DS: 22
Cons: 22

Damage and DPS per ability:
JoM DPS: 845,83 - DMG: 203000
CS DPS: 450 - DMG: 108000
DS DPS: 412,5 - DMG: 99000
Cons DPS: 458,33 - DMG: 110000
Melee DPS: 1000 - DMG: 240000
SoM DPS: 575 - DMG: 138000

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

Simulation time: 240 seconds.
Judgement cooldown: 8 seconds.
Priority: cs > jom > ds > cons
Total DPS: 3762,5

Number of casts:
JoM: 28
CS: 39
DS: 22
Cons: 22

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

Simulation time: 240 seconds.
Judgement cooldown: 8 seconds.
Priority: cs > ds > jom > cons
Total DPS: 3772,92

Number of casts:
JoM: 28
CS: 37
DS: 23
Cons: 23

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

The same calculations with a 7 second judgement shows the following:

--------------------------------------
Simulation time: 240 seconds.
Judgement cooldown: 7 seconds.
Priority: jom > cs > ds > cons
Total DPS: 3877,08

Number of casts:
JoM: 34
CS: 34
DS: 23
Cons: 22

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

Simulation time: 240 seconds.
Judgement cooldown: 7 seconds.
Priority: cs > jom > ds > cons
Total DPS: 3908,33

Number of casts:
JoM: 33
CS: 39
DS: 22
Cons: 22

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

Simulation time: 240 seconds.
Judgement cooldown: 7 seconds.
Priority: cs > ds > jom > cons
Total DPS: 3877,08

Number of casts:
JoM: 31
CS: 38
DS: 23
Cons: 23

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

Theese numbers might not be correct, since I'm not really sure about the average damage on the different abilites. I haven't really raided much, so I don't have much WWS-data to go by, and the numbers I get from Redcape's sheet seem a bit too high. They are suggesting that I'd do around 5k DPS, but I'm only in heroic/emblem/10-man gear, and I'm usually ending up around 3,5k DPS in 25-mans. I'd be happy to run a few simulations with some "real" numbers if anyone has any good data.

I'm hoping I'll have the time to finish this little application in the weekend, so I might be uploading somewhere if someone is interested in giving it a go. There's just a few things that needs to be sorted out before I can let someone else use it :)

(Woah, that's a long first post :) )

Am I right assuming that we could add Latency to the GCD? (ex gcd=1.8 for 300ms)

Not really, latency influences the time when the cooldown actually starts. There are three important events when you cast a spell :

-The time your client tells you the cd is over
-The time you launch the spell (client side)
-The time it takes for the server to confirm to your client that the spell is cast (this is where latency comes into play)

The important thing to know is that when you are almost off the gcd or the cd of a spell, your client can send a cast request to the server (this change was done recently, during BC). However, the server still has to confirm that you can (and did) cast the spell, this is the latency we experience. This is also why people like me with an average of 8 ms ping, sometimes have between 100 ms and 300ms of latency while casting a spell. It comes from the server taking time to process the information my client sends.

PS: forgive my english, I am french. If I am not clear enough, I can try to explain it differently.

Well, the simple way would be to just make the GCD a bit longer, and I think it would actually be pretty close to the truth.

What happens is probably something like this: (Let's assume 200ms latency and lightning reflexes)

0.00 You press a button to cast a spell.
0.20 The spell get's casted (This includes sending a message to the server, and getting a response)
0.20 Your GCD is started.
1.70 your GCD ends
1.70 You press a button to cast a spell
1.90 The spell get's casted (This includes sending a message to the server, and getting a response)
1.90 Your GCD is started.

The best way to implement it would simply be to add your latency to the timer right before every cast, and only then. That would solve most problems with CD's and GCD, although it will mess things up if you're using melee dmg in your script.

I added latency to my application, and some simple calculations shows that there's quite a large amount of DPS lost due to latency. I added latency right before a spell is cast, which should be pretty close to reality.

With average numbers from my latest WWS my tool suggests 4190DPS with a CS>JoM>DS>Cons rotation and 0ms latency in a 240sec fight. With 100ms latency I'm down to 4017DPS, 200ms puts me down another step to 3820DPS.

With a few extra calculations on different sets of gears, different latencies and different lengths of fights my calculations suggests there is about 3-5% of DPS loss for every 100ms latency added, which is quite substantial.

Zengir, I've noticed a similar loss progression with my version of the script. I'd be interested to run some identical test cases with your script and my script and verify that they come up with essentially the same thing. Do you have a link posted to where your script can be downloaded/used? Or do you want to run some cases, let me know the results, and then I can run the same ones?

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

As for other tests, I was asked to do a couple of things with the script. One was to verify that any amount of delay prior to judgment was a bad idea in the long run. (IE, to verify that FCFS has no exceptions to the "if something is off cooldown, use it" rule.) To do this, I ran eight tests: with/without 4pT7 vs. with/without delay before judgement, at latency = 0 sec and latency = 0.200 sec. Damage numbers were pulled straight from Redcape's spreadsheet. (Exemplar, I checked yours but I couldn't find where in all those cells you had a damage-per-cast number for the various abilities; all I saw was DPS. Am I missing something?)

All tests were run for a 300 second (5 minute) fight duration. I commented out the simulation log, so only the results came through. In all test cases I assumed an undead target, ie, Exorcism and HW were valid attacks. (This also more accurately simulates 3.1, given the upcoming Exorcism change.) I was using my updated version, v002, of the script, as currently displayed in the first post.

Here are the results (sorry for the wall of text):

Test 1
4pT7 = False
Delay before Judgement (if within 0.5 seconds) = False
Latency = 0.000 sec

Test 2
4pT7 = False
Delay before Judgement (if within 0.5 seconds) = True
Latency = 0.000 sec


Test 3
4pT7 = True
Delay before Judgement (if within 0.5 seconds) = False
Latency = 0.000 sec

Test 4
4pT7 = True
Delay before Judgement (if within 0.5 seconds) = True
Latency = 0.000 sec

Test 5
4pT7 = False
Delay before Judgement (if within 0.5 seconds) = False
Latency = 0.200 sec

Test 6
4pT7 = False
Delay before Judgement (if within 0.5 seconds) = True
Latency = 0.200 sec

Test 7
4pT7 = True
Delay before Judgement (if within 0.5 seconds) = False
Latency = 0.200 sec

Test 8
4pT7 = True
Delay before Judgement (if within 0.5 seconds) = True
Latency = 0.200 sec

In other words, delaying for judgement does cause a small DPS loss in every single case tested. This is a confirmation of FCFS "conventional wisdom." One interesting result is that doing a judgement delay when not using 4pT7 seems to consistently conflict with Crusader Strike coming off cooldown immediately before judgement, thus Crusader Strike's cooldown gets artificially set to Judgement's cooldown. Without the delay, CS and J interweave more easily in a non-4pT7 environment.

Also note that latency in and of itself causes ~100 DPS difference per 0.1 second of latency, at least as modeled here.

Brilliant. Left, sent you a PM with directions to find average dam per cast in my spreadsheet.

I'm going to try to install Python and run some tests with your script (not that I don't trust your results). Start modeling the new Exo but no HW (3.1 assumptions) in 7 and 8 seconds. Also some borderline cases I was considering while I was staring at manual models. Like if Judge is under 0.5 seconds and Exo is up, skip Exo, but not the other abilities. Or CS. Etc. If I find anything unusual I'll post it here. I suspect it may sometimes be a win to pause that half second, but this is a gut instinct and against common wisdom and all our math to date.

Great tool, I plan to use it to enhance the next version of the spreadsheet that I release (with yet more accurate rotation information - probably extrapolating out to 6hrs as recommended earlier in this thread). I highly recommend those using Redcape's excellent spreadsheet also use this to figure out their own real-world rotations.

My application can be downloaded here:
RapidShare: Easy Filehosting
I think you need .NET 3.5 framework to run it.

It's far from complete, and not the least bit user-friendly. I made it purely for my own use, but you're all welcome to try it out. It should be pretty self-explanatory, but just send me PM if there's something you're wondering. The same goes if you have any suggestions or requests.

Your application loads, however it has issues with what the priority setting should be. Also, you can enter the same priority for abilities to get strange results.

Also, it should include Exorcism 15 second cooldown.