I am giving serious consideration to writing a DPS simulator for Warriors and would like to gague interest as well as solicit input from the potential users.

What it would do: Input your unbuffed stats, talents, buffs, encounter info then output DPS-relavent statistics of varying verbosity, to include: avg DPS, min/max DPS for interval x, min/max hits/crits, rage generation (rps, min/max rps for interval x), min/max/avg stats (AP, ArPn, Haste, etc), proc stats

What it would not do: Paper doll - Easy enough for me to add another sheet to the current spreadsheet to handle data export, maybe even write an automated export method if I feel industrious. Coding a paper doll method would involve a lot of stuff that I am not sure if I know how to do. Maybe it'll come eventually, but the priority is the sim, which mostly involves stuff I am pretty good at.

Interface: Right now, I am looking at doing a simple windows-based GUI with a style similar to the spreadsheet for buff and talent input (lots of checkboxes and listboxes) and something similar to dr_AllCOM's 2.0 sheet (the foundation for Warrior_Sim.xls in my sheet).

That's what's on the top of my head. I'll be coming up with more ideas as I ahift focus to this project, and hopefully the community will have some input too.

Rawr 15 already has a module for Arms Warriors, so I don't what you are trying to show that Rawr does not.

I believe Rawr is still just a pretty spreadsheet(and nothing against Rawr). A simulator goes far beyond that, especially when calculating such headaches as flurry uptime.

I think it's a great idea. Build it now for current wotlk abilities/talents/builds and update it as they change stuff. I really liked your old spreadsheet grim i'm sure you'll do a fine job on a sim. I wouldn't waste any time or effort making a lvl 70 one however.

As mentioned above Rawr will not do a fullscale simulation but rather emulate the spreadsheets. In my opinion this is kind of pointless, a full scale simulator is way more interesting. Secondly, Rawr b15 is not even released yet, so why are you bashing on someone for doing a new thing?

Anyway, I think it would be highly interesting Grim13. I've started writing a simulator myself, but there is never enough time to work on it so I'd rather use whatever you can make. I think it will be really hard to figure out optimum cycles for dps warriors in wotlk, having a swing simulator where you can set rage priorities (e.g. give priority to the ability with highest damage/rage in ragestarved conditions) will be a great tool.

Ohhh, now there's some interesting stuff Gruntle.... Thinking along the lines of being able to set thresholds to tweak the decision process. As in, making the cycles somewhat dynamic, based upon user specifications. This is really getting my wheels churning, thinking of stuff like setting rage thresholds for pretty much everything....HS, execute, MS/BT, etc... Plus, it would REALLY help clear up some things with Slam cycles that spreadsheets have a really hard time with, especially the bursty nature of 2h rage generation. Ohhh, I'm also thinking about learning this XML stuff so that it can interface with the armory to pull your current gear. Really, doing that is a step towards paper doll functionality, which I have not ruled out, just not likely to be in the first version.

I hope to get the updated sheet out this week and then start work on this. Just tough to make time for this, the sheet, the web site and actually playing the game. Not to forget work too, heh. I should be able to do this though. I can kinda visualize the functions in my mind for a lot of the stuff needed for this project. Just need to learn how to do a GUI and I'l be off to the races.

As to the concern over doing it for lvl 70 vs lvl 80, 95% of the stuff will remain unchanged. The hard part is the mechanics. Once I have a modular framework coded for the warriors base mechanics, adding new and different stuff should be easy. That is one thing about this project: since it will be 100% my work from the start, I'll be able to use the type of modular framework that I prefer. Not to condescend towards the original authors: it was great work, it's just different methods of overall design. Not that any of this matters to anyone so long as it works, right? Actually though, if I follow through with the principles I intend to focus on, it should make it MUCH easier to add new gizmos.



Ok, enough with all that, I'm thinking about the "time scaling" of the thing, and how to do it. Right now, I am leaning towards writing everything at real-time, but with a multiplier variable built in that is user definable. Like, so they can run the thing slow(or just less fast) if they want, and watch the action unfold. Like, maybe so they can personally watch things over for rage starving or whatever they may want to look for.

Which makes me think of another idea: Rage bar and target HP bar, updated in time with the sim, of course. Would make the watching over of some things a little easier.

All this talk about time, I also need to decide on a resolution for the simulator. 0.01s? 0.001s? One of those two most likely, I'd imagine. I'll probably make that adjustable as well, if it can be done without too much hassle. No idea how much of a resource hog the thing might be. I think, instead of the user being able to enter whatever they want, I'll just have 3 choices: Low, Medium, High. Like, 0.01s, 0.001s, 0.0001s, or whatever I end up using. The ability for the user to reduce the timing resolution by an order of magnitude could be handy, as it's a pretty significant difference to the CPU.

You may think this sort of stuff sounds minor, but this is the kind of stuff that makes for a MUCH better program if it is foreseen and implemented from the beginning. We need to come up with EVERY feature and option you guys can think of. I need to design the base framework properly to handle it all. I would really like to do this right, because there are some things I suspect will come out a bit different than they do in the sheets.

It's not immediately clear to me that you need to set a specific, fixed resolution like that; it seems to me that it might work better to seek from event to event. That is to say: almost all events that are of interest in this sort of thing are either triggered by a cooldown being up, or an attack being launched. For instance: a proc cannot occur without a weapon attack. Rage cannot be regenerated without launching an attack (usually). Abilities with cooldowns can't be used until the cooldown is up. And so on. Hence, rather than checking the status of the character every .001 seconds (or whatever), it's probably more efficient just to build up a sorted list of events. For instance, if at T=0 you land an autoattack with a 3.0 speed weapon, you add to your list an entry for "next autoattack" at T=3.0. If you then land a Mortal Strike at 0.5 seconds, you add an entry to the list for "MS cooldown up" at T=6.5. If the MS procs DST, you add an entry for "DST buff fades" at 10.5 seconds. At any given time, there's thus a reasonable short list with perhaps a dozen elements in it specify when the next interesting thing can happen. Your program can this just step through this list - at each instant in time, grab the "interesting event" that's going to happen next, update the list based on that event, and repeat. If no interesting event is possible for the next 1.5 seconds, there's no real reason to make 1500 checks while you're waiting - you can just seek that 1.5 second forward and get on with the show. Seems to me that this would result in a less computationally intensive simulation than just checking the status of everything every .001 seconds.

Yeah, an event driven code will most probably be a lot faster than having a fixed resolution. The stuff I started to do was in Python and with a fixed resolution. I'm not really an expert on optimization but only the white hits and rage generation seemed to be very slow with a 0.001 resolution. Too many loops are spent doing exactly nothing. I started to remake it into using events, but then my vacation was abruptly interrupted by having to go back to work .

I'd be willing to help out as well if you need, not sure how much time I'll have but feel free to ask.

In regards to adding an HP/Rage bar, I can understand having the rage bar, but how are you going to simulate the HP bar? Without doing encounter specific programming i mean. I think that is going much past being a simple simulator and into being encounter by encounter raid simulator. It seems to me that if you wanted to the the HP bar you would have to know: current encounter, how many healers present, what type of healers, the healers +healing/crit rate. Just seems much more complex than a simple tank and spank sort of simulator

He did say "target" HP bar. As in, "Is it Execute time now?" Not that there wouldn't be some tricks involved in modeling that too, of course.

So he did. Im an idiot, that makes perfect sense now