I think this is a great idea, if done correctly. If not apporached with the right frame of mind this cuold turn into a huge nightmare, Grim. The strengths of this idea is so huge and I wish it could be easy but I fear that there are an overwhelming amount of variables to be able to build enough loops for. Is this a brute-force project or a finesse project? A combination of both?
An event-driven system I fear could propogate into inaccuracy inflation. For example, if the calculated swing time was 2.93 seconds but in reality was 2.9348732 via calculation, that .0048732 could add up over time to be 3 seconds over a long fight. Multiply that by 10 different mechanics, and the automatic decision making engine will start making incorrect decisions even if one mechanic is slightly off.
Computer processors are pretty fast these days. Even with a 1ms (.001s) resolution we just don't know how fast it will run. It might just be that what you think would be slow having too many instances going through too many loops, might be too fast for you to even be able to follow in a display.
Haste mechanics I fear will completely run you around. What happens when you crit on your off-hand whirlwind, proccing DST and a new flurry when your main hand is in mid-swing? You would have to take the remainder of your main hand swing's time and add the haste application to only that section.
The problem of procs is that they are not static. How could you update dynamic changes to the warrior's stat table to your calculation loops while the loops are running?
Give it a shot, but make the code available for the community to see, test, and comment on. This project is going to be a big deal, with lots of little small parts forming into bigger and bigger parts that will finally come together. You could probably start working on it now and have untalented mechanics working befre the final WOTLK changes are made. Build the input, and an auto attack loop and let's see how it looks!
Make it resolution based, because at least that way you can make a variable that defines time left on swing that can be modified on the fly. Procced haste while midswing? then you do "Set Swing_Left =Swing_Left/(1+Haste_Proc_Percent).
Ask for a lot of help. You sound like you may not know a lot of neat programming tricks, which is what will be needed here. I don't know very much myself, but there are plenty of people I'm sure that do who would also have interest in helping.
What I would like to see:
For a display window, have 3 seperate columns streaming events with timestamps. Column 1 would have auto attacks and heroic strikes, Column 2 would have special attack damage, and Column 3 would have buffs gaining and fading.
Dude, you're pretty much right on the exact same page as me. Flurry and similar proc-based haste mechanics make event-based a bad idea, imo. Have to be able to handle those mid-swing procs. Really, that is my entire motivation for taking on this project: To get a more accurate picture of warrior DPS. From the spreadsheet work I've done, I can see where there are some serious issues. People mentioned ones like mid-swing haste, flurry up-time, rage spikes/starvation, etc... Another HUGE deal though is execute when dual-wielding with different speed weapons. There is simply NO good way to model this in a spreadsheet. I don't have a lot of confidence in the model I currently use for execute speed in the spreadsheet. It's a lot better than a lot of the other methods that have been used, but at the end of the day it's still a stop-gap.
I'm wanting to do this because I am interested in the results, and because it looks like a fun challenge for me. Language-wise, I am most likely going to use C++, since it's the only language I really know. All this new shit like Java and Python and C# wasn't invented yet when I learned how to program. I do think I'm gonna say fuck the GUI for now and use data file input.
Ohhh, another idea that popped into my head....maybe do support for two different configs and have them run side-by-side. Like, if you want to use different rage spending parameters or different specs or something.
Also, I don't know what my availability for working on this is going to be for the near future. There is very likely going to be a strike starting on Sunday. I am a contractor, so not only will I still be working, but I'll be working 12 hours per day, 6 days per week. Now, if it's really dead here that means MORE time to work on stuff, but with so many less people, I may end up getting swamped. No idea how long the strike will last either. We'll see. I mainly say this as a reminder to people to be patient. I intend to follow this project through. It's just gonna be a little slow getting off the ground.