Edit: I also adjusted my lookahead Rake/Rip code to ignore SR falling off (since the expectation is that it's up most of the time) and also discount factoring in crit to avoid unnecessary clips during Banner/Terror in Mists/etc..

Also, if you set any stats to identical weights, there might be multiple near-maximums (when you reforge exhaustively), so I need to add a tie breaker, or maybe better, a way to add an additional constraint linking any pair of stats with a ratio.

I got proc scaling implemented for all feral-related trinkets.

I added PvP Power and Resilience stuff, and added support for a human player target type.

Added simc support for cycle_targets=1 and did more work with multi-targets.

When I started development, I was just thinking of doing 1 target, since that's typically what everything is evaluated against. But then I found out there were some AoE scripts, I figured multi-target was worth it.

Now that I've added multiple static targets, I kind of feel that, what I should of implemented is some kind of combat script, similar to DBM or BigWigs, that allows you describe the fight.

To my disappointment, DBM and BigWig scripts are implemented as fight-specific lua rather than some generic combat DSL, so that kills my idea of just directly interpreting them.

The tricky thing is that all this stuff interacts weirdly with the action lists and is difficult to configure via the interface. But, even with very basic combat script support, I could move away from the monotonous Patchwerk sim. (I see that Mew had some Theralion and Valiona support and Simc has some Helter Skelter support.)

So I'm trying to figure out a simple set of commands and triggers that would allow me to setup combat scripts for a bunch of fights. Just looking at what we have on live: Stone Guard (multi-target, linked HP), Spirit Kings (sequential, overlapping spawns, dot-wipe/shields), Wind Lord (aoe, linked hp), Protectors/Garalon (multi-target), Blade Lord/Lei Shi (periodic downtime).

Some fights would obviously be way too complex to implement w/o being paired with specific action lists, but still, anything more realistic seems better than tank and spank.

What I'm thinking is:

1. command to define an enemy class (this is where you can link hp pools by using a shared name, add race type human/beast, can block, behind/front)2. command to spawn an enemy class under some identifier (or in batch, like spawn 10 blahs's)3. trigger at some time (relative to combat time or enemy spawn time)4. trigger at some % hp (relative to enemy)5. commands like: RunAway(enemy,time), ClearDebuffs(enemy), Die(enemy), Immune(enemy), etc...6. commands that apply mods: BuffStat(Agility, 1000, 10sec), BuffMod(All, 50%), etc...7. commands to make an enemy suffer some external raid dps (since I'm only simulating one feral)

Way back during early Cata, I implemented an Atremedes script of sorts by halting all yellow attacks for 30 seconds. Yawning followed that up with a variety of changes that made it viable to test different fight scenarios (including fixing the one thing that I could not do in my script at that time - turn off white attacks during the air phase). My goal was to test different stat value setups across a variety of fight scenarios. This was when 4.06 came out and the stat values were becoming close enough that it didn't make that much difference what people focused on. I made a blog post about this at that time: http://fluiddruid.net/2011/03/4-06-the- ... ary-stats/

I am bringing this up to add a little color to your thinking about what to add to your simulator. It is interesting to see what talents are rotations work best on given fights, and it is also interesting to be able to compare different reforging/gem setups.

The goal would be being able to express most fights in a few lines of code.

All targets would be standing at the exact same position. You could tell any target to run away (not aoe-able), gain flags like, disable-melee or disable-all to prevent new incoming damage, etc..

I needed a way to import raid DPS so I added a (suffer XYZ) to any target/health pool, to model external raid DPS. The simulator could then jiggle it.

The Elegon script requires more ideas, possibly it's too complex for what I was intending to support. Most of what I played with in that file can be implemented pretty easily.

If a fight has a 10 minute enrage, I don't know what to do if you don't kill it; same thing applies with mechanics like Elegon sparks (although possibly, the spark count could purely depend on you, with the assumption that you're the only fail DPS in your raid :p)

You could probably implement a script purely as a timeline, where you just have triggers every 10 seconds or so, that sync the fight (approximate target HP and deaths) to an actual WoW parse.

Probably the script should be able to cast Raid spells (like Heroism, Stormlash, Banner) and somehow make suggestions (kill this!, use HotW hurricane, etc...) or enable/disable druid abilities (never mangle, use potion).

Overall, I don't know if optimizing on a per-fight basis would be very useful. It might help figure out better stat weights though if you simulate a basket of encounter scripts.

The big problem about modeling raid situations/encounters really isn't the fight/enemy part, but the action lists of the players playing this scenario.

So even if you offer very complex fight modifications, the simulated players aren't going to specialise themselves to that situation, unles you have very complex action list specializations.

In SimC, the unofficial compromise is to offer some generic options which can significantly alter the outcome of even a patchwerk like fight, but don't go down the path of modeling individual combat mechanics ( and that's also mainly because we're lazy ).

Important target options are certainly enemy start and end health pct. Both have big impacts on execute stuff, or in cataclysm on some 90%+ abilities. A 10min enrage can be done by just doing a 10min sim and checking if you did enough damage ( or how many % of your iterations did ).

Been a while since my last update, I haven't had much free time, and I've been really bogged down learning stuff about Java, but my X-mas vacation begins today!

@Caltiom, yeah I agree, the need for fight-specific action lists means that this is much more complicated than I intended. I'm currently supporting a simple N number of targets, and then try to work out something later for more interesting mechanics.

I found a bug in UnitDamage(), http://us.battle.net/wow/en/forum/topic/7394209929 , basically, I cannot compute the same damage the Lua API spits out when I'm in Cat/Bear form. Everything works fine in Human form. I've been hunting for bugs, trying to make sure everything matches in-game. My guildies make fun of me because I'm always hanging out near the target dummies.

As for my simulator, I got the rest of my interface linked up, so all options now work. Ursol's Vortex is usable, as well as the strange 1-2 tick Rip Extends. I added more support for various miscellaneous features like "proper Rip extends" where you only get what the tooltip describes (1 tick extra, max of 3), or "allow TF during Berserk" to see what kind of DPS boost it potentially would allow, as well as a few others. I'd like to have a whole bunch of weird enable/disable features to help isolate the value of various things.

I fixed a bug with my simc importer (using wrong talents) as well as enabled loading in the race/glyphs/talents/gear from the provided simc comments (although it's difficult to interpret the gem expression: eg. "agile_80agi_80hit_180agi" is hard to parse in the general case.)

I added basic saving (window position + other interface settings) + the ability to import/export all settings from a file (in addition to autosave).

I'm still working on some basic HTML output and trying really hard to get useable release available.

Are you going to provide a way to define a character by raw stats in addition to by gear so I can easily compare different stat values? One option that would be cool would be able to run a series of runs with stat points being shifted, say 100 at a time, so for instance, you could start with 1000 haste and 3000 crit and end with 3000 haste and 1000 crit. It would need to be able to do a large number of iterations at each point, but when it was done we would have a better idea of how the two stats actually compare to one another (and how they interact).

For fight simulation, consider adding something that allows you to specify being off a target for a period of time. This needs to include a way to shut off white attacks in addition to the specials.

From a rotation development perspective, it seems like we can either use simc scripts, or do some Java coding - but the Java coding will require that we can compile the full simulator, unlike Mew, where the script was compiled on the fly without recompiling the source. Am I correct in my assumptions?

I can do the raw stat thing, I just don't know the best way to implement it. Prior to running the simulator, it takes a profile worth of gear + buffs + racial + class stats and mushes it down into simple stat vectors for fast lookup. Food/Flask are implemented as just merged into an "extra stats" variable that's added on top.

So, if you had a naked profile, and just supplied "extra stats", then everything would work, but if you specified "1000 agility" it would be sitting on top of (food + flask + race + class) + buffs, so it really wouldn't be 1000 agility. Also, I'm not sure how the weapon would work in this situation, I guess just min/max? Or supply DPS and do 0.80/1.20 for Min/Max.

Or, with a geared profile, I could just have a simulation option that walks through all possible reforgings between two stats. So load a profile, setup reforger for hit/exp cap, give Mastery a lower bound, and then do Sim of Haste-to-Crit (if there's too many permutations, have a minimum step of 100 or w/e).

I'm still debating about the script stuff. Right now I've got partial simc support (100% of the current druid script, but I haven't added all the simc options that are available in the sim). Doing the Mew runtime compile of a java-based script is definitely an option.

What kind of options would you want for the target unavailable thing? I feel that I need to come up with an API for what actions/fight mechanics I can support before I start adding too many features.

Maybe the interface is too much bloat for someone actually trying to improve the rotation. My original intention was just designing something that anyone could download, run, hit import, and then experiment with different talents and gear. But maybe, if I had a java-based (or some custom) script, that could specify everything in text, I could bypass the interface all together, and just generate results.

Man, I severely under-estimated the difficulty of completing my simulator. With fixed stats copied directly from in-game, I got the basic simulator working in a few hours (re: first post). A few days later I had the Blizzard importer working. Soon after, a nice interface and simc support. But after adding multi-target support, I've been stuck. (Although I did add support for the bear-thrash thing. I'll try to post some numbers in that thread soon.)

It's almost impossible to provide a simple interface to configure all the various combat options that I want to use, yet trivial if I had some kind of syntax to describe the fight, targets, and method of combat. From an interface, it's too easy to setup something that makes no sense, and too complex to design something useful.

I just finished my second attempt at a target configuration panel, and I realized how fucking tedious it is to use. I think a much better method would just be a list of various combat scripts, kind of like the dungeon journal, with virtually no interface controls over enemy health, positioning, level, race, dodge, parry, block, uptime etc... Having consistent scenarios to simulate against seems much more useful than a bzillion unmanageable options.

So, I'm currently working on two things: 1. I'm returning to my idea above and experimenting with ways to design/describe complex fights via code and 2. move my internal action list away from java, and into a form, like the simc script, that can be embedded into the fight scripts.

This means a few things:

1. I won't be able to offer many options via the interface that impact the rotation. I was initially planning on having all kinds of various options to play with different ways of doing the DoC rotation, or using Rake spam, or w/e, but I think all of this customization is too complex for a GUI and must be moved to scripts.

2. User-controllable things like Heroism, Stormlash, Shattering, etc.. cannot be triggered from the interface (only allowed/prevented) and it's becomes scripts job to use them. ie. triggering Heroism late rather than Early will require separate scripts.

3. For the normal user, you'd just download my utility, import your cat, pick a script, and get some answers; a developer would primarily be developing fight scripts in a text editor and barely using the interface beyond the initial setup.

So basically, the simulator will be two-pieces: the paper doll (w/gear/gems/enchants, buffs/debuffs, allowed spells, enable/disable bugs, etc...) and the combat simulator (action list merged with fight script). Both of these representations will have a file equivalent, so it should possible to take a "BiS_Gear.catus" setup and simulate "WindLord.brawl"

At my request, Yawning added the ability in Mew to specify name/value pairs when running a script. We sued those to choose different scenarios/tests. That allowed me to switch between the scripts without the basic code having to change.

my preference continues to be able to write scripts in a high level language (Java or whatever) rather than being restricted to a predefined script language. It does require a decent api of course. Maybe you could implement a LUA front-end

If you want to get a feel for how we used name/value pairs, take a look at the default script that ships with Mew. You will see a place in the code that pre-processes name/valu pairs and sets up some variables that control the script.

Leafkiller wrote:At my request, Yawning added the ability in Mew to specify name/value pairs when running a script. We sued those to choose different scenarios/tests. That allowed me to switch between the scripts without the basic code having to change.

my preference continues to be able to write scripts in a high level language (Java or whatever) rather than being restricted to a predefined script language. It does require a decent api of course. Maybe you could implement a LUA front-end

If you want to get a feel for how we used name/value pairs, take a look at the default script that ships with Mew. You will see a place in the code that pre-processes name/valu pairs and sets up some variables that control the script.

... and so forth. This could also be used to put several rotations into a single configuration file (HotW, DoC) and you could post a commented header to decorate the tags with some information used by the UI (coloring, description, etc.)

Leafkiller wrote:my preference continues to be able to write scripts in a high level language (Java or whatever) rather than being restricted to a predefined script language. It does require a decent api of course. Maybe you could implement a LUA front-end

The main advantage of a custom script/syntax is that I can translate/compile it into something more optimized, validate it for mistakes, and avoid unintended exclusions. But I agree, having the freedom to do more via a script is awesome from the development perspective and avoids the need to abuse and mangle a lesser-script to emulate some missing functionality.

Just in the last week or so we have two new threads: 2 target rotation and bear-weaving, both requiring different setups, and still they're just cleave-patchwerk and aoe-patchwerk.

I think there is some middle ground, where I can provide some features (Enemies, Timers, Events, Priorities) and then have simc-like if-expressions for computation with the ability to have a tagged/hierarchical Action list that can be modified as the fight progresses. To avoid repeating the same core rotations, I need some kind of import() functionality, so the primary single target rotation can be referenced/used in multiple fights.

Also, there needs to be a way to expose some variables used in the script, back into the interface: for example, a single target Patchwerk brawl could expose an "HP" variable, so the script wouldn't need to be duplicated just to change the fight length. This is very similar to the mechanics of Mathematica's Manipulate: http://reference.wolfram.com/mathematic ... ulate.html

Another concept that I'm playing with, is allowing for second-pass optimizations. Where you run the simulator a few times, and collect some data, to help optimize the rest of the rotation. For example, if you setup a complex fight, you might not know where the best place to blow Heroism. Additionally, you might not know if your fight has a combat time that allows you to use heroism twice, or if there is a 6 minute enrage preventing 3 berserks. So you could run the initial brawl a few times, build up a plot of damage over time, and then trigger Heroism or Potion, or w/e at the optimal points automatically, instead of defining them manually.

There are probably many other optimizations that you can do, beyond simple autocasting, if you had an approximate damage profile of the fight as you simulate it.

raffy wrote:It's almost impossible to provide a simple interface to configure all the various combat options that I want to use, yet trivial if I had some kind of syntax to describe the fight, targets, and method of combat. From an interface, it's too easy to setup something that makes no sense, and too complex to design something useful.

Yep. I am the world's worst UI programmer and it showed, though people say I came up with something that was passable. One fo the main things I was planning for my Mewtwo refactor/rewrite was to carve off encounter specific code into a separate script and give it more library code but since I never actually got around to writing Mewtwo, it remains something I was thinking about.

raffy wrote:So basically, the simulator will be two-pieces: the paper doll (w/gear/gems/enchants, buffs/debuffs, allowed spells, enable/disable bugs, etc...) and the combat simulator (action list merged with fight script). Both of these representations will have a file equivalent, so it should possible to take a "BiS_Gear.catus" setup and simulate "WindLord.brawl"

That is how Mew worked from the beginning, since I wrote it that way. User interface should be abstracted away from the concrete implementation (Though 99% of the users used the GUI I wrote, instead of the command line interface which I mostly used for testing).

Leafkiller wrote:my preference continues to be able to write scripts in a high level language (Java or whatever) rather than being restricted to a predefined script language. It does require a decent api of course. Maybe you could implement a LUA front-end

If you want to get a feel for how we used name/value pairs, take a look at the default script that ships with Mew. You will see a place in the code that pre-processes name/valu pairs and sets up some variables that control the script.

Are you trying to make me feel guilty about getting bored with the project?

That stuff was schedule for a rewrite that I briefly touched on, but it's non-trivial to do cleanly (though most people did not touch script implementation). What we had worked for all of our use cases and left developers with enough flexibility to do everything we envisioned at the time though so as far as a design to crib off it's not bad.

raffy wrote:The main advantage of a custom script/syntax is that I can translate/compile it into something more optimized, validate it for mistakes, and avoid unintended exclusions. But I agree, having the freedom to do more via a script is awesome from the development perspective and avoids the need to abuse and mangle a lesser-script to emulate some missing functionality.

Using a higher level language gets you "translate/compile/optimize" for free. "validate" is non-trivial beyond syntax errors and basic "doh" type bugs (It's actually flat out impossible to completely solve if your expression language is Turing complete)., so I viewed the tradeoffs as worth it.

Tangedyn and I spent time screwing around with the Mew script functionality to write fractal renderers (I did an ASCII art one and Tangedyn one-upped me by writing one that used Swing). I also had one that checked e-mail because why not ("Every program attempts to expand until it can read mail.").

As a side note mostly towards leaf, I've been reliving the past by using http://sensi.org/~svo/glasstty/ in my text editor. I'll probably go back to my usual font soon because I miss having bold punctuation and a zero with a slash, but it's amusing for now at least.

@Yawning - Definitely a classic terminal, and one I used at various times. Way back (in the ice age) I had 2 HP 2621Ps in my possession, one at my home and one in my room at college. They were complemented with 212A modems and, as I was working at Tymnet at the time, I had world wide access long before there was an internet, at 1200 baud!

I'm very familiar with what you're talking about, but I'm not intending to expose a high-level language. I want to support a syntax that allows a developer to express things simply. Most fights are just a bunch of interleaved timers and triggers.

While this greatly limits what you could potentially do with it (no fractal render or w/e), this does allow me to convert the script into a timeline and/or a bunch of evented-actions that can execute very efficiently.

If instead, I implemented a simulator w/hooks, where I'm constantly notifying a delegate about whats going on and have no knowledge of it's state or intention, I have no room for optimization or ability to validate silly actions as you said. Optimization isn't really a goal either (but speed is nice). I'd much prefer correctness and an execution that matches in-game to a simulation that runs fast but can't be trusted.

The AoE Bear Thrash thread is a great example (although not a fight/boss related thing). Ignoring the simc bugs, where do you stick that desire in the action list? Why is it implemented as multiple actions interleaved with the normal rotation? Why can't it just be like: (if conditions met to AoE thrash) -> might of ursoc or bear -> thrash -> maul? -> dash or cat

While a pretty crazy goal, I think the next step in improving feral performance, beyond executing the single-target tunnel rotation, is being able to ask questions about "when is the best time to use ABC for fight XYZ?" And this requires something more complex than a 1-dim action list, but something much simpler than a full-blown you-can-do-whatever-you-want callback system.

Overall, I think it would be very cool to be able to simulate a relatively complex fight, with a relatively simple script, and generate a damage over time plot that approximates real world of logs data.

I can put a source link up too later today. I haven't had a lot of time to work on it (which is why it looks about the same as did from a few months ago) so it's still kind of a mess and not organized. Instead, I've been unsuccessfully trying to develop that Brawlscript idea (from above), but every implementation I choose just ends up being way more complicated than I intended.

I might just temporarily inline a hack for this since these items are rare.

Edit: for the time being, you can go into Catus root directory, and browse to /Cache/raffy.antistupid.com and locate "Item_-96540.json". You can edit this file an add two entries into the "bonusStats" array for the corresponding secondary stats.

You can also use this method to create custom items of your own design by just creating a new file with a non-conflicting item-id, and then adding the corresponding item-id to Gear.txt

Oh just the paperdoll stuff, Catus works great for that stuff. And with my wowhead/JSON thing, it's easy to import any PTR gear. I'll upload a copy tomorrow that you can play with, configure gear, and reforge stuff. I'm still in the middle working on the Brawl script thing so everything is a mess right now.

Edit: you can download Catus here: https://dl.dropbox.com/u/2989349/Catus.rarTo add PTR gear, add them into Gear.txt using negative item ID's (there are examples in there)Lots of output is dumped into stdout so you might want to launch the jar via a console to see additional stuff.But if you just wanna setup gear and reforge stuff, it's setup for that.Edit: added missing assets, and included some cached data by default