I talked to two of the Wowhead developers. They are planning on making more information available via XML feeds like the one I described above, but there are higher priority bug fixes and enhancements they're going to focus on first.

I'm seeing about creating an option on the "Talents" and "Spells" nodes (libraries of talents and spells available to the simulation, not to be confused with the allocation of talent points for a particular character), where you can import a *.dbc file directly from your WoW installation. This action would create a bunch of spells, and a "talent representation"* for each class (i.e., a new balance, feral and resto tree for the druid class model). This cuts WAY down on the maintenence required for each class, since spells and talents can be grabbed directly from the WoW client installation (or PTR client even). In case anyone is interested, here's what the structure of these tables looks like

Talent.dbc - Source Peek Wiki
Spell.dbc - Source Peek Wiki

Things I still need to look up on a site like Wowhead:
1) Anything at all relating to items
2) Anything at all relating to quests
3) Consumables

I like the idea of being able to do a "find as you type" search, so I'll probably cache some abbreviated item data. Being able to grab stuff from the WoW client's itemcache.wdb file would be fantastic too, as I don't want my software to rely on Wowhead working perfectly to function. Of course there will always be the option of adding gear manually

I haven't posted here in a while, because I have made a major change to the way I'm getting spell/class/talent/mechanics information.

Right now, I pass in several CSV files (comma separated value -- a very human-readable format for tables). I was expecting to just get spell names, ranks, etc... but there's a HUGE amount of information in the *.MPQ files in your /World of Warcraft/Data directory. This includes things like valid target types, proc rates, shared cooldowns, how many times debuffs can be stacked, etc... for all 38,000ish spells in the game (remember, this is for NPCs too).

I'm going back and eliminating anything I sort of 'hard coded', because I want to base as much as possible on this data.

The advantages to you, the users, are two fold:
1) You can rely on any information obtained from the game client to be perfectly accurate.
2) You can rely on any information obtained from the game client to be completely up-to-date.

I'm hoping that there will be very little upkeep for each class, and that users will be able to simply load new game data into the simulator each time their client is patched.

I have looked more closely at what is stored in the WoW data files (your itemcache file in your WDB directory), and finding out what you have in your bank from your own game client is certainly possible. It's not an extremely high priority right now, but there are things I want to get from those file anyway (i.e., items your character has seen, to avoid going to wowhead for every single piece of armor).

Here's an issue I've rehashed so many times that I now lack any perspective whatsoever. I'm afraid I'm missing something obvious, so I would very much appreciate ideas:

I have this object called AttackRotation. Essentially, after a character's attack, the AttackRotation is asked what the character's next action should be. An AttackRotation contains one or more Priority objects.

Here's a little conceptual overview of how these things work in my simulator:

Attacks can do the following things:
1) Tell you the spell associated with them, which tells you the base damage, cost, type of cost (i.e., combo points, energy, or a combination), etc...
2) Tell you when the attack will next be ready (takes cooldown, group cooldown, global cooldown and your character's state into account -- mana, health, etc...).
3) Tell how "safe" it is to perform the action, based on your character's current state (i.e., don't lifetap or SW if you're below 20% health). Note that these are things that are risky, in the sense that doing them may get you killed. There will be a parameter somewhere that you can set somewhere in the range of "maverick cowboy pirate ninja" to "scaredy cat". There will be a check somewhere else to make sure you don't actually commit suicide, but this is where you'd make sure you don't lifetap yourself to 4%.
4) Tell how "smart" it is to perform the action, based on your character's current state (i.e., don't start casting something if you have a debuff that will stun you before you get the spell off). Note that this is NOT designed to help you "pick the spell", but rather to avoid doing something that, while normally appropriate, isn't because of some special circumstances.

A Priority can do the following things:
1) Tells you how well an Attack satiefies the Priority. For example, a shadowpriest may have a priority like KeepMiseryUpPriority, which would be designed to reapply misery to the current target if it is not up, or has less than 3 seconds left. In this case, it would tell you that Shadow Word: Pain, Mind Flay and Vampiric Touch all will reapply Misery. The priority will tell you that the previously mentioned three Attacks all applly Misery equally well.
2) Tells you the Priority's "urgency". In the above example, if you have just applied Misery to your target, it's not all that important that you consider reapplying it again. However, a priority like DoMaximumDamagePriority will usually have the same "urgency" all the time.

An AttackRotation can do the following things:
1) Tell you what the highest Priority at any given moment is(this is simply sorting by the "urgency" mentioned in point 2 above)
2) Tell you which action to take now*. In the above example regarding the KeepMiseryUpPriority, if misery is about to fade off the current target, KeepMiseryUpPriority would likely be the highest (returning Attacks: SW:P, Mind Flay and VT). The next priority might be DoMaximumDamagePriority which would essentially pick one from the three Attacks. The AttackRotation now knows to do that attack next.

* This may actually end up being "which action to take next".


So, the TL;DR is:
* A Priority has some criterion (i.e., "Keep your threat at 95% of the tank's, or below", and it looks at your current situation (taking you, your party, your enemy and the phase of the moon into account) and tells you based on many factors how important it is.
* An AttackRotation starts with all your available Attack, and, in order of importance, goes to each of its Prioritys and asks which one is best.
* Each Priority then asks each Attack how "safe" and "smart" it is, given your character's state, your party's state, your enemy's state, etc..., and makes sure that it's within your specified "riskyness" level. The Priority then looks at how well each of the provided Attacks satisfies the intention of the priority, and passes the group of best Attack choices to the next highest Priority.


SO....

Can you guys think over how you decide which is the spell to cast (including NOT casting anything) at any given moment and time, and let me know if it's similar to the concepts above? If you can find a scenario that couldn't be modeled by the above decision process, please post it here so we can figure something else out.

A good way to do this is to go through the following thought process:

Imagine your grandmother is sitting at your computer, controlling your character, but she doesn't know a thing about WoW. You must explain to her exactly what to do before she starts fighting, but once she starts you can't say anything at all. You may assume she can make very complicated decisions on the fly, she knows nearly everything about the state of her character and her party/raid's characters at every moment, and she has complete information on all properties of all spells, talents, items, etc...

Thanks!

At least as a frostfire mage, that is a reasonably complete view of my decision making process. To crib from Manly's epic treatise:

His priority queue seems like it would be easily modeled by your system. That would get you about 90% of the way to modeling a tank and spank fight, with the rest being cooldown management.

One of the trickier things I can think of offhand is mirror image, as Manly alludes to. It does a small but noticeable amount of damage over the course of a fight, so if you are trying to go balls-out, you want to pop it during your all-cooldowns-blown burn phase. However, on some fights, mages may choose to keep it in reserve as a defense mechanism (you pulled aggro after Noth blinked) or not use it at all (they like to randomly shoot at Gluth zombies). Even more aggravating, if you are very close to or above the tank in threat, popping MI will cause the images to instantly pull aggro, potentially doing Bad Things (think Malygos breath).

It's an edge case, but the edge cases are often the most interesting and useful to model.

Human perception and experience always include the timeframe in these decisions. It's like Rawr with the fight length parameter, but it is relevant in all decision making points. This includes CD juggling, debuff times and estimated fight length left, perhaps also estimated time to live with known or guessed dmg-in.

Possibly make time-states for which you calculate weights with Priority and Attack parameters. Either that or have the timeframe as a priority or an attribute of a priority. The time-state with the heaviest weight should then be the winner of that rounds decision making.

In the above example you need to know whether you have time or resources (mana, rage, energy) to do something else in addition to A that ends up being more powerful than B. The goal I think is to gain maximum effect for desired action (dps, threat, heal) in the remaining time by utilizing all your resources to the fullest.

This is clearly the case, but calculating the objective function (i.e., damage, threat, healing done) for every possible scenario is unacceptable. I'm trying to model the way a human makes decisions anyway, and we certainly don't do this type of evaluation while fighting.

I would think that the best, and possibly easiest way, would be to allow someone to set their abilities in a list for their priority.

Something simple like:

<Ability A>
<Ability B>
<Ability C>
...
<Ability G>

Or whatever....then have the simulation taking into account mana, regen, etc, etc...and start at the top "Is Ability A available?" If yes, then do <Ability A>, then go down the list. If the cooldown, or duration of the ability isn't up yet, then the answer would be "no" and it would go down to the next ability.

Cycling through these until OOM or the "fight" is "over".

it's the best way I can think - with an Affliction spec, it's now us Warlocks do things - start with the initial series of spells, then refresh things as they come up, rinse, repeat.

You can display associated threat levels after each rotation, etc, if you know the values....but your comment about how we don't do that type of evaluation (unless I misunderstand) while fighting, isn't wholly true. Something weird happens, and I find I'm about to take aggro from the tank (or whatever), I'm changing my rotation to lower my threat (as an example)....

My musings.

I think you misunderstood what I was saying, or I was unclear. Redbeard, above, was talking about deciding what action to take "now", based on figuring the whole optimal sequence of actions from "now" until the end of the fight. This is like those amazing chess players who can see 20 moves ahead, and my response was that I don't believe players don't make decisions that way in this game. I think that they mostly just look at their cooldowns, their resources (mana/rage/energy/ruinic power/combo points/runes), their own health, the health of the boss, etc... I doubt most players think more than 10-15 seconds ahead, aside from waiting for key abilities to cool down.

I believe what you're describing fits my model above. You could create "Priorities" for
* Staying under tank threat
* Keeping your health above 60% via healthstone/drain life
* Keeping your important debuff(s) up (i.e., you keeping your malediction-amplified curse up may be more important than doing damage)
* Keeping your mana above 50% via lifetap/dark pact
* Doing damage

I believe that this priority system needs to be more complicated than what you're using for simulationcraft for two reasons
1) I'm dealing with multiple players, attacking (eventually) multiple targets. If warlock A, B, and C need to collectively keep curses of elements and shadow up, and warlock A puts elements up, casting curse of elements becomes vastly less important for all three warlocks until the debuff starts to expire.
2) I want to model the death knight class properly. I don't believe that the concept of NOT spending a rune on ability A now, because ability B (a better choice) will be ready in the near future, can be modeled by anything less complex than what I have above. For example, if I currently have one unholy and one frost rune, and a blood rune cooling down in 2 seconds, I can either cast obliterate (consumes 1u1f) or take an autoattack swing and cast death and decay in 2 seconds (uses 1b1u1f).

If I have a simple list of abilities, and ask each one, in order of priority, if it's ready to use, there are two possible scenarios:

A: death and decay is a higher priority than obliterate
* Ask death and decay if it's ready (NO)
* Ask obliterate if it's ready (YES)
* Cast obliterate

B: obliterate is a higher priority than death and decay
* Ask obliterate if it's ready (YES)
* Cast obliterate

I believe that the simplistic list of abilities in priority order will NEVER cast death and decay, regardless of whether it's a better or worse spell than obliterate in a given situation.

3) I want to avoid forcing users to plug in a rotation they read somewhere on these forums, because that information is based on incomplete theorycrafting. There's no doubt that using spreadsheets for analysis is useful, but it fails to take many factors into account that I am attempting to model.

As far as usability is concerned, one of the perks of using Java and Netbeans is I can throw together a slick "Create custom attack rotation" wizard in about 10% of the time it takes me to code up the mechanics of choosing an attack. No coding will be required in my software, unless you want to perform an optimization of some sort, where you run many simulations, adjusting parameters as you go. Even then, the code would only be making the adjustment, and telling the simulation to generate a new set of results.

I'm just making sure I have a model that fits every class well and MOST player behavior well, in the context of multiple raiders in multiple parties attacking multiple targets. Anything less complete has already been done, and is thus not worth doing again.

Ah, ok.... If you want to support multiple targets that certainly adds an order of magnitude in complexity. The simple priority scheme in SimulationCraft works fine for the multiple-players-single-target that it was designed for.

Each player action inherits base conditionals such as: Is the cooldown up? Is the DoT still ticking? Is there sufficient resource? However, the custom conditionals that have been coded into some abilities were for precisely the type of scenario you describe. The main difference is that I only provide a discrete set of conditionals as opposed to the generic framework you have proposed that makes every possible piece of information available. I guess I'm just saying that there is a cost to complexity that is not readily measured. In my software experience, I've seen Feature-Frenzy eat up too many promising projects.......

My reference to code reviews was not really about people working up different action priority systems using your infrastructure, but reviews of the core code itself. I've found the EJ community to be a fantastic resource for fine-tuning the player models. Keeping the barrier to entry as low as possible without compromising on too many design goals should be something to strive for......

So am I correct in understanding that any use of SimulationCraft at all requires coding of some sort?

I think I've addressed this issue in two ways
1) I'm getting as much information as possible from the game client. I don't rely on users/developers to get the spells right, but instead I pull all 38,003 of them from the MPQ files. I believe that this dramatically reduces the upkeep of the program as talents/mechanics change
2) For the things I can't get from the game client (i.e., how the crit/hit/miss roll works), I have decided to make the mechanic as isolated as possible from the rest of the program. For example, insead of putting the code that does that roll on line 862 of my simulator.java file, I make a new class that does nothing but conduct that roll. Thus, getting a "code review" on that one file will be easy, since you don't have to deal with the non-wow-related workings of the software.

In response to the feature frenzy comment, I'm just trying to get a discussion going about this stuff. I won't get to implementing the attack rotation stuff for a while. The alpha test will most likely just let you set up a pre-determined rotation.

My mistake, I thought you had to code up even basic spells (i.e., simulationcraft knows nothing about "chain lightning"). Using a config file certainly makes things much easier, and a typical analysis would just be reordering things in said file, not requiring a recompile.

This is certainly one of the more time consuming things to implement, as there's an INCREDIBLE amount of information about the spells. Just making the various objects that hold this data has taken me several days. When I set out on this project, I intended it to be a framework upon which people could build their own programs and take advantage of the library of spells, talents, characters, etc..., but this has slowed me down considerably. I don't necessarily need to know that spell of ID 55369 creates an item of type Mace and subtype Two-Handed Mace, but I figure the information is available so I may as well parse it. I even have positional info, like the radius of AoE spells, the # of nearby targets a spell can jump to (if applicable), etc... which would make adding positional information to simulations possible (don't get your hopes up, not coming anytime soon )

Send me a PM if you're interested in learning about this stuff, and how you can add it to simulationcraft. A lot of the work involved in using this data is finding out what is what. Nothing is labeled, so you have to figure out what each column of numbers means via induction, and I would have no problem sharing that info with you.