Catus: Edgy's Cat Simulator (in development)

[Caltiom]

I'd call myself a (hobby) programmer, just not for Java, and much too lazy to go after that problem I encountered myself But it is always interesting to look at new code, and would be a great opportunity to hack around a bit.

It's always great to have to have other Theorycrafting tools to compare results to. If someone is very motivated and has a LOT of time, then that is great. Otherwise, improving the existing technology may have been the "more effective" choice. Especially the collaboration between all the classes with only 1 User Input/Output, GUI, etc. system can be a big gain, or lets say that is often what theorycrafter don't want to do as well.

Kitty theorycrafters seem to be very oldschool, hardcore players. The first DoC breakdown would certainly be possible in SimC, but the detailed list would be too much Maybe someday if we have better statistical capability with to-disk storage instead of keeping everything in memory during runtime.
All your action lists, even more your detailed Ovale scripts, would be way over the top for most other classes. In fact, some other "normal" action lists are deemed "unplayable" by some other community sites ( even though their skill level might not be that high ^^).

Leafkiller: I didn't completely understand your third point, what exactly you'd need in the action expression system. I'm sure we could give it a try - or maybe we already have something similar somewhere. You're right that it is much harder to change something like this in SimC, which goes deep into the core architecture because of its universality.

[raffy]

I remember using Mew back in the day, but I never looked at the code. I just did a checkout and it's pretty interesting. I like the idea of having the "action list" as a java class file.

Right now, the "core" of my simulator exists as like a single 5 kloc java file :p as I've yet to split it up into individual classes. My focus has been on trying to making implementing new abilities as simple as possible. I had linked aggixx my stormlash implementation last night as an example: http://raffy.antistupid.com/wow/catsim/Stormlash.txt

I definitely understand the desire for more "state" in your action list, and Mew's java implementation provided that. I think I can eventually offer something similar.

For example, a feature I've been playing with is a push/pop/swap system for hierarchical action lists. For example, I initially start with 1 action list (I call them Logic's) that is my main rotation. To implement the opener, I push an Opener logic, that pop's itself after it does whatever it's supposed to do. This way, for the rest of the rotation, I never need to check/consider Ravaging. When I activate HotW and want to cast, I push a WrathSpam logic, that pops itself once Wrath.castTime > HotW.timeLeft or upon HotW fade event. During HotW, no extra code needs to be evaluated. These are just some simple examples. I've been using the same system to implement things like "wait for energy, while buff x, y, z remains, then run this new logic".

I'm wondering however, at a more theoretical level, what's the best way to describe our rotation? I have a feeling that it's more like a directed graph, but I don't think the graph can be hand-constructed (due to it's complexity and maintainability).

I'd actually be really interested in developing some kind of syntax, that can express our rotation concisely, that can then be compiled into something more manageable for the simulator to use. For example, I was considering was compiling the rotation into mini-action lists based on energy (0-100 would give 101 lists) but that seemed to have issues with energy cost modifiers but still is interesting.

It seems like you're encountering some of these issues in Ovale, like when you need to pull resources but you want to indicate what spell you're trying to execute.

I think the key is having some simple yet expressive way to describe our rotation then using a compiling step to turn it into a simc-script or whatever kind of input my simulator accepts. That way, more people can help develop and improve the script without adding significant features to the actual simulator. The only caveat is that there needs to be sufficient information available to the script (re: simc not providing proper tickMultiplier).

The problem with Mew's java approach is that it severely limited who could actually develop the script, whereas many people come to this forum and ask questions or make suggestions involving the simc and/or Ovale script since it's much more readable.

Java is not my first choice; I originally considered using Lua for my simulator but worried about native threading and the gui interface.

[raffy]

In fact, some other "normal" action lists are deemed "unplayable" by some other community sites ( even though their skill level might not be that high ^^).

This is a really good point as well. Another starting point would be working backwards from "what can a human actually do" when equipped with an addon like Ovale or something similar. Maybe I should add an Ovale importer.

[Leafkiller]

Kitty theorycrafters seem to be very oldschool, hardcore players. The first DoC breakdown would certainly be possible in SimC, but the detailed list would be too much

I am not sure what you mean about being possible in Simc (are you just referring to the feeling that what we have is too complex to check in?). We have implemented the rotation in simc with only one current limitation (see below).

In fact, some other "normal" action lists are deemed "unplayable" by some other community sites ( even though their skill level might not be that high ^^).

I don't have any good answer for that. I am aware of how much more complex our rotation is now, but that is very much Blizzard's doing. Both our best tier 4 talent, Soul of the Forest, and our best tier 6 talent, Dream of Cenarius add a tremendous amount of complexity. Even if we trimmed out all of the early clipping code there is no way to do DoC effectively without knowing when to cast Predator's Swiftness+Healing Touch and/or Nature's Swiftness+Healing Touch. Soul of the Forest adds in a balancing act between keeping Savage Roar and Rip up versus aggressively using Ferocious Bites to take advantage of the the energy return we get from SotF. Using Ferocious Bite effectively is worth at least 3% of our DPS in the DoC rotation.

Leafkiller: I didn't completely understand your third point, what exactly you'd need in the action expression system. I'm sure we could give it a try - or maybe we already have something similar somewhere.

Mostly with Mew it was easier to get changes in because Yawning was very motivated when he first built it and I was his most active user. Technically, I am not a hobby programmer and when I do program (outside of maintaining the Ovale script) I am working on a startup writing an Android app. I have not spent the time to learn the simc code. The primary maintainer of the simc feral script, aggixx, has also not done a deep dive into the simc code. My third comment was mostly about being able to quickly get changes in the sim engine that allowed me to test the rotation, and hopefully simplify it, although that has become very difficult with the current feral talents.

At this point the one major thing I am missing is the ability to query for current and predicted tick damage on Rip and Rake. Currently we are using dot.rip.multiplier, dot.rake.multiplier and tick_multiplier, but these do not take into account attack power, and our BiS trinkets along with our combat potion all provide agility procs which mostly give us more attack power.

Periodically aggixx and I try to rebuild the rotation seeking some way to simplify it, but so far we have not found a good solution. I think we will continue to do that, and as our understanding grows, we might stumble onto something. At least the rotation is executable with Ovale, and for those who do not want to use a move suggester, Droodfocus now provides damage ratio indicators so people can tell when it is a good time to clip Rip or Rake if they want to execute an advanced rotation.

Maybe the solution for what we check in would be to limit the conditions we use for early clipping and to try to simplify some of the conditions on aggressive FB usage (which just got more complex, but added 1.5% to the DoC rotation dps). We can also simplify the checked in script by removing the code for other talent combinations. A fair amount of the code in the rotation is for Incarnation (Tier 4), Heart of the Wild (tier 6) and Nature's Vigil (tier 6). At least once we had a simpler rotation, we could measure it and see how much we lose when we don't the advanced actions.

[Caltiom]

Kitty theorycrafters seem to be very oldschool, hardcore players. The first DoC breakdown would certainly be possible in SimC, but the detailed list would be too much

I am not sure what you mean about being possible in Simc (are you just referring to the feeling that what we have is too complex to check in?). We have implemented the rotation in simc with only one current limitation (see below).

I was refering to raffy's very detailed breakdown of ability usage, in the text file he linked.

In fact, some other "normal" action lists are deemed "unplayable" by some other community sites ( even though their skill level might not be that high ^^).

I don't have any good answer for that. I am aware of how much more complex our rotation is now, but that is very much Blizzard's doing. Both our best tier 4 talent, Soul of the Forest, and our best tier 6 talent, Dream of Cenarius add a tremendous amount of complexity. Even if we trimmed out all of the early clipping code there is no way to do DoC effectively without knowing when to cast Predator's Swiftness+Healing Touch and/or Nature's Swiftness+Healing Touch. Soul of the Forest adds in a balancing act between keeping Savage Roar and Rip up versus aggressively using Ferocious Bites to take advantage of the the energy return we get from SotF. Using Ferocious Bite effectively is worth at least 3% of our DPS in the DoC rotation.

I have nothing against complicated rotations, but maybe they should be implemented for BiS only, and not for the default proposed action list in SimC when someone imports his druid.
That said, SimC supports multiple, named action lists, which can then be freely combined and whatnot. I'd have to dig into that, but in theory we would be able to offer 2 action lists when someone ( or the BiS profiles ) create the action lists. A normal one, let's say with 97% dps and a 2 times more complex one from you guys with 100% dps

Leafkiller: I didn't completely understand your third point, what exactly you'd need in the action expression system. I'm sure we could give it a try - or maybe we already have something similar somewhere.

Mostly with Mew it was easier to get changes in because Yawning was very motivated when he first built it and I was his most active user. Technically, I am not a hobby programmer and when I do program (outside of maintaining the Ovale script) I am working on a startup writing an Android app. I have not spent the time to learn the simc code. The primary maintainer of the simc feral script, aggixx, has also not done a deep dive into the simc code. My third comment was mostly about being able to quickly get changes in the sim engine that allowed me to test the rotation, and hopefully simplify it, although that has become very difficult with the current feral talents.

At this point the one major thing I am missing is the ability to query for current and predicted tick damage on Rip and Rake. Currently we are using dot.rip.multiplier, dot.rake.multiplier and tick_multiplier, but these do not take into account attack power, and our BiS trinkets along with our combat potion all provide agility procs which mostly give us more attack power.

Periodically aggixx and I try to rebuild the rotation seeking some way to simplify it, but so far we have not found a good solution. I think we will continue to do that, and as our understanding grows, we might stumble onto something. At least the rotation is executable with Ovale, and for those who do not want to use a move suggester, Droodfocus now provides damage ratio indicators so people can tell when it is a good time to clip Rip or Rake if they want to execute an advanced rotation.

Maybe the solution for what we check in would be to limit the conditions we use for early clipping and to try to simplify some of the conditions on aggressive FB usage (which just got more complex, but added 1.5% to the DoC rotation dps). We can also simplify the checked in script by removing the code for other talent combinations. A fair amount of the code in the rotation is for Incarnation (Tier 4), Heart of the Wild (tier 6) and Nature's Vigil (tier 6). At least once we had a simpler rotation, we could measure it and see how much we lose when we don't the advanced actions.

There are various undocumented ( we're too lazy! ) dot expressions at http://code.google.com/p/simulationcraf ... ot.cpp#342 , for example .tick_dmg which returns the last ticks damage ( including crit damage, I think ), or .attack_power, etc. Should be fairly easy to guess what the expressions are doing by looking at the code.
I'm not sure how you would do more stable tick_dmg expression: I guess it would have to exclude crit damage, and possibly target multipliers ( which are dynamic, not tied to the dot application itself ). Or how are you doing this in Ovale?

[Leafkiller]

I have nothing against complicated rotations, but maybe they should be implemented for BiS only, and not for the default proposed action list in SimC when someone imports his druid.
That said, SimC supports multiple, named action lists, which can then be freely combined and whatnot. I'd have to dig into that, but in theory we would be able to offer 2 action lists when someone ( or the BiS profiles ) create the action lists. A normal one, let's say with 97% dps and a 2 times more complex one from you guys with 100% dps

What if the difference is 10-15%? I think that is the dilemma we are facing in the feral world, where the delta between a simple rotation and an advanced rotation is more than it is for most other classes. It is true that we (ferals) are somewhat to blame since we have taken the time to squeeze out so much extra dps. I have considered seeing how some of the clipping rules would apply to other DoT classes just to share the pain, and I know that some locks have been playing with that

There are various undocumented ( we're too lazy! ) dot expressions at http://code.google.com/p/simulationcraf ... ot.cpp#342 , for example .tick_dmg which returns the last ticks damage ( including crit damage, I think ), or .attack_power, etc. Should be fairly easy to guess what the expressions are doing by looking at the code.

I will see what I can find there.

I'm not sure how you would do more stable tick_dmg expression: I guess it would have to exclude crit damage, and possibly target multipliers ( which are dynamic, not tied to the dot application itself ). Or how are you doing this in Ovale?

I don't think we are taking into account target multipliers. I don't think those should matter. We are looking at all the buffs that are up including Tricks of the Trade (we verified that one recently). For a full explanation of what we are doing in Ovale, I would have to ask Jeshu (aka Nerien and jlam) as he is the one who coded it.

It took awhile to find it, but here are the key posts from Jeshu when he made the change to Ovale for this:
http://fluiddruid.net/forum/viewtopic.p ... =125#p8481
http://fluiddruid.net/forum/viewtopic.p ... =150#p8523

Edit: Adding the actual Ovale script code to make this clearer:

Code: Select all

# Rake functions
AddFunction RakeTickDamage
{
    # rake_tick_damage = (tick_damage + coeff * AP) * damage_multiplier * bleed_multiplier
    Damage(RAKE) * {1 + Mastery()/100}
}

AddFunction LastRakeTickDamage
{
    # rake_tick_damage = (tick_damage + coeff * AP) * damage_multiplier * bleed_multiplier
    LastSpellEstimatedDamage(RAKE) * {1 + LastSpellMastery(RAKE)/100}
}

AddFunction RakeTickDamageRatio
{
    if TargetDebuffPresent(RAKE) {100 * RakeTickDamage()/LastRakeTickDamage()}
    unless TargetDebuffPresent(RAKE) 100.0
}

[Leafkiller]

Adding to my last post, I exchanged some PMs with Jeshu when I put the Ovale code together and here is a very short explanation he gave me for how Damage() is calculated:

Code: Select all

base
    + bonuscp * combo
    + bonusap * AP
    + bonusapcp * AP * combo

This is based on how Rip and Rake have been defined:

Code: Select all

Define(RAKE 1822) #cat bleed
    SpellInfo(RAKE combo=1 duration=15 energy=35 tick=3)
    SpellInfo(RAKE base=98.13 bonusap=0.31453)
    SpellAddTargetDebuff(RAKE RAKE=1)
    SpellDamageBuff(RAKE dream_of_cenarius_damage=1.25)

Define(RIP 1079) #cat bleed
    SpellInfo(RIP resetcounter=ripshreds duration=16 energy=30 tick=2 combo=0)
    SpellInfo(RIP base=112.76 bonuscp=320 bonusapcp=0.0484) # damage coefficients
    SpellAddTargetDebuff(RIP RIP=1)
    SpellDamageBuff(RIP dream_of_cenarius_damage=1.25)

I don't see any mention of other buffs in there, but I know they are being tracked. I will ask him about that.

[Jeshu]

I should update the documentation for the Damage() and LastEstimatedSpellDamage() conditions. They do take into account damage multipliers due to buffs on yourself. The correct formula used in Ovale is:

Code: Select all

(base
    + bonuscp * combo
    + bonusap * AP
    + bonusapcp * AP * combo) * damageMultiplier

Damage() uses the current values; LastEstimatedSpellDamage() uses the values at the time the spell was cast.

The damage multiplier doesn't take into account debuffs on the target that increase damage taken because WoW takes those debuffs into account each time a DoT ticks, whereas buffs on yourself are taken into account at the time the DoT is cast. This approach lets you see whether the DoT you're applying ticks harder than the DoT you're overwriting, without caring whether the target has temporary damage-taken debuffs or not.

The current list of buffs that factor into the damage multiplier calculation are in OvaleData.lua:

Code: Select all

OvaleData.selfDamageBuff =
{
	[5217] = 1.15, -- Tiger's Fury (druid)
	[31665] = 1.1, -- Master of Subtlety (rogue)
	[52610] = 1.3, -- Savage Roar, glyphed (druid)
	[57933] = 1.15, -- Tricks of the Trade (rogue)
	[84745] = 1.1, -- Shallow Insight (rogue)
	[84746] = 1.2, -- Moderate Insight (rogue)
	[84747] = 1.3, -- Deep Insight (rogue)
	[124974] = 1.2, -- Nature's Vigil (druid)
	[127538] = 1.3, -- Savage Roar (druid)
}

If any of those percentage increases are incorrect, or if there are other buffs that should be taken into account, please let me know. Sometimes, there are temporary buffs that you gain in a raid setting that increase the damage you do, e.g., stand in the glowing circle and do 30% more damage, etc., and it would be nice to get a list of those buffs in the current raid tier.

[Leafkiller]

As I was looking at the old posts last night, I was wondering why Mastery was not part of Damage(), i.e. why am I calculating the following in my script:

Damage(RAKE) * {1 + Mastery()/100}

[Jeshu]

Regarding the damage buff from feral mastery, I didn't see how to easily hook it into Ovale without becoming overly cat-specific. I've been trying to move more of the class-specific logic out of the Ovale core and into script logic instead.

Still, I think class-specific knowledge is somewhat hard to avoid altogether, so I might make class-specific modules to encapsulate the logic and have the core engine call out to the module when needed. Currently, there is class-specific logic in the Ovale core for monks, druids, and rogues.

[Leafkiller]

Regarding the damage buff from feral mastery, I didn't see how to easily hook it into Ovale without becoming overly cat-specific. I've been trying to move more of the class-specific logic out of the Ovale core and into script logic instead.

Still, I think class-specific knowledge is somewhat hard to avoid altogether, so I might make class-specific modules to encapsulate the logic and have the core engine call out to the module when needed. Currently, there is class-specific logic in the Ovale core for monks, druids, and rogues.

After I posted that, I realized that Mastery does not buff DoTs for all classes, and even varies within a class depending on specialization (Warlocks being a good example) so including Mastery in the damage calculation will require knowledge of which spells mastery affects for each class/specialization that uses DoTs. It does pose a documentation issue though, should any other class (such as afflic locks) try to build a rotation using the damage conditionals.

[raffy]

I should probably verify this stuff again, but prior to 5.1, I computed Rip and Rake base tick damage to be:

Code: Select all

    double _ripTickDmg()  { return getRazorClawsMod() * (900 + combo * (2560 + 0.3872 * getAP())) / 8; }
    double _rakeTickDmg() { return getRazorClawsMod() * (99 + 0.3 * getAP()); }

These were within 1 damage of in-game across various gear sets.

Thrash:

Code: Select all

int ap = getAP();
double dmgMod = catDmgMod(doc) * getRazorClawsMod();                
double initDmg = dmgMod * (0.191 * ap + range (1103, 1360, true)) * targetBleedMod();         
double tickDmg = dmgMod * (0.141 * ap + 686);
double critDmgMod = 1 + critDmgMods.product;
if (atk.crit)  initDmg *= critDmgMod;
if (atk.block) initDmg *= targetBlockMod;

[Instaqueues]

I know I don't understand all the technical jargin...but I like what you're doing! I have 1 suggestion to help with your HotW testing though. Have an option for your HotW caster staff that you switch to, so DPS can be measured more accurately during your wrath-spams. Then of course it'd switch back to normal agi weapon after HotW expires.

Oh...and love this entire site!

[raffy]

Have an option for your HotW caster staff that you switch to, so DPS can be measured more accurately during your wrath-spams. Then of course it'd switch back to normal agi weapon after HotW expires.

In this screenshot http://raffy.antistupid.com/wow/catsim/sim_ui4.png, you can see when HotW talent is enabled, you get a new configuration panel for "Heart of the Wild", which lets you choose Passive/Wrath/Tranq/Hurricane/x2/x3/x4/x5, perform a weapon swap, and then choose a weapon (auto gem'd) and an enchant (and I guess I should add a reforge).

[Instaqueues]

Oh! That's great! A reforge option would be good for more exact DPS. I really think this little area is what separates this great simulator with simcraft. There seems to be so many detailed things inside a rotation that it's hard to capture with a generic "import character and simulate" program!

Great work!

[raffy]

Oh! That's great! A reforge option would be good for more exact DPS.

http://raffy.antistupid.com/wow/catsim/sim_ui5.png shows the start of the Reforge interface. My reforger is multi-thread, monte-carlo or exhaustive, and supports a linear objective, single-interval constraints, and reforge exclusion. Code example:

Code: Select all

new ReforgeAlgo().atLeast(StatT.HIT, 2540).atLeast(StatT.EXP, 2540).setWeight(StatT.MASTERY, 1.00).setWeight(StatT.CRIT, 0.90).setWeight(StatT.HASTE, 0.80).dontReforge(StatT.MASTERY);

Reforge exclusion is actually pretty cool because it allows you to avoid Mastery > Hit/Exp.

For some gear sets, this might require the evaluation of nearly a trillion gear permutations, although typically I can reduce the space down to under 50 million (which exhaustively completes in under a second) but it lets you find the perfect combination. Plus, it means when I do simulations that swap trinkets or gear around, I can dynamically reforge them, before each simulation.

You can see a reforge dump here: http://raffy.antistupid.com/wow/catsim/Dump4.txt

So many damn edits:

Also, my regem interface allows you to either blanket replace gems based on socket color, or apply one color everywhere unless the socket bonus is worth it. I'll post some new screenshots when I get home from work.

Additionally, all idiot checks are performed so basically any equipment error you get in-game (invalid slot, socket bonuses, mh/oh weapon exclusion, item/gem uniqueness, etc..) exists for my paperdoll as well.

[aggixx]

How you've had the time to develop all of this so fast I have no idea.

Sounds better and better all the time, and I'm looking forward to being able to actually use it

[raffy]

Still no release yet (spent the last two days wayyyyyyyy getting fucked over by the item upgrade stuff). I'm busy writing some software to analyze a few thousand mop items, to see if there is actually any method to Blizzard's madness for item stat distributions, or if actually, each god damn piece of gear is allocated willy-nilly.

Latest paper doll (w/upgrades):
http://raffy.antistupid.com/wow/catsim/ ... pgrade.png

Collapsable interface (w/summaries) and beginnings of Simc Importer interface:
http://raffy.antistupid.com/wow/catsim/ ... llapse.png

Reforge (w/smart fill) and Cat stats:
http://raffy.antistupid.com/wow/catsim/ ... eforge.png

[raffy]

Getting closer to a release, currently I'm testing Windows support.

I removed the preferences for Old/New Dancing Steel etc.. and just moved everything over to RPPM.

My upgrade stuff seems to be dead on (no more off by 1 errors) for all stats, armor, and damage scaling. Only feature I have left to implement is scaling procs.

Got an updated simc importer, that also can pull in the gear and stuff (and report errors, since my simc support is not complete). Also, it can pull the latest simc script from this forum (grabbing the test inside the spoiler block in the simc thread).
http://raffy.antistupid.com/wow/catsim/sim_ui8_sim2.png

Added icons, to make gear configuration easier:
http://raffy.antistupid.com/wow/catsim/ ... _icons.png

Just working on the simulation result stuff now.

[raffy]

Here is a very basic release:
https://www.dropbox.com/s/d55hnk760p58g ... im_003.rar

You can launch the application by just opening the Sim2.jar assuming you have Java Runtime installed.
Latest JRE: http://www.oracle.com/technetwork/java/ ... 59586.html

I recommend launching via command line, by cd'ing to that directory and using: java -jar Sim2.jar

On the first launch, it needs to download a bunch of things. It should be much faster after the first launch, mine launches instantly, but I only have access to machines with SSD.

All of the simulator and reforger output is dumped to stdout, so if you don't launch via command line, you won't see any useful output.

However, the interface is fun to play with, and great for figuring out gear setups. A bunch of features don't work yet via the interface, they're implemented but don't have interface hooks. There is no saving.

There is a bunch of configuration files, which are pretty self explanatory and easy to edit. If you have a gear setup that you like, if you left-click on the item level value in the Equipment pane, it will copy, what I call the CompactGearRepresentation, to your clipboard. You can paste this code into a text file, and add it to the PremadeGear folder if you want to save a configuration. "Gear.txt" contains item ids of gear recommendations for any slot. "Gems.txt" contains suggestible gems. "HotwSwaps.txt" will contain MH/OH configurations.

I'm pretty sure my Cat Stat calculations match in-game for any gear/enchant/race/profession/upgrade configuration, but if anyone finds anything silly, let me know. They will not match armory, as armory is often wrong. If you click on any piece of gear via name, it will open that link at wowhead.com.

The SimC importer has difficulty when importing the AoE script since it cannot figure out the /use_item for hand slot. If you replace the "something_something_grips" with "hands", it will work properly, but I don't have a target setting available so it will only AoE 1 target :p

The reforger constraints are hard-coded currently, as I've yet to figure out a good interface for it. The regem "unless good" option also depends on stat weights that are currently not editable and is not functioning currently.

Consumables are not currently extracted from the interface, nor are some of the Edgy's Rotation settings. Opener Potion and HotW opener isn't gui linked either.

Lifeblood will not be used in most simc script as it is not in the action list. Same with any other lesser manual effect. The simulator will warn you if anything you're wearing is unimplemented. If you don't behind and use certain scripts, that only cast Shred, it won't use any generators. I think I'll just make simc's Shred "smart", so it uses Mangle when Shred isn't available (and maybe Ravage or Rake depending on talents and gui options).

I haven't tested the Blizzard Import with weird realm names, possibly I need some url escaping. I also need to add the TW region.

Java is not my primary language so there are probably exceptions, errors, and edge cases I have overlooked.

Edit: sorry for a zillion edits, keep forgetting things

Edit: looks like theres an Import bug if you have Barkskin, I typed that Glyph into the enum twice :p

[Caltiom]

Great work, thanks for the release!
A few quick questions that come to mind:
* Is there a special reason you didn't ship the source code along with it?
* How do I "simulate" multiple, custom specifiable iterations? With error estimates and all? Or how are you compensating for the variance?

I can't say much about the kitty content of it, but I'm sure others will

[raffy]

Nope, http://raffy.antistupid.com/wow/catsim/Src2.zip

This is like version .0001 in terms of what you can do with the interface. I just figured it's dumb if I keep bumping my own thread talking about some wazoo vaporware.

You'll def have support for that very soon. Lots of targeting options, nice HTML output, etc.

Edit: you mean like,
1. setup simulator
2. append to list
3. change some stuff
4. append to list
...
X. Simulate All? Yeah, great idea.

[Yawning]

I was talking to Yawning a few months ago bemoaning the loss of Mew as a tool we could use and he said good things about Simulationcraft and the people who work on it. He said he developed Mew because he was interested in creating a simulator and the classic "NIH" ("not invented here").

Correct. Writing a discrete event simulator isn't the most complicated thing by a long shot but it was an amusing distraction.

2. It was easier to work on the rotation in Java because I could implement basic things like if/else structures and functions (not to mention Java is closer to Lua which is what the Ovale scripts use). aggixx will confirm that there are things that are much easier to express in my Ovale script than they are in the simc script.

You mostly have tangedyn to thank for that since he was the one that suggested the library I ended up using and helped me with some of the aspects of using it here and there.

@Raffy - as a side note, did you ever look at the source code for Mew? It is written in Java and could give you some ideas of how to address some of the issues you are talking (such as latency, etc.). https://code.google.com/p/mew-wow-druid ... e/checkout

Don't think I ever ended up implementing latency though it would have been trivial to do, since it would just have increased the stddev. All the code except for the third party libraries is 3 clause BSD licenced (though I was particularly inconsistent about tagging them with copyright), so people should feel free to crib code from there, though it isn't anything all that special.

I'm wondering however, at a more theoretical level, what's the best way to describe our rotation? I have a feeling that it's more like a directed graph, but I don't think the graph can be hand-constructed (due to it's complexity and maintainability).

I'd actually be really interested in developing some kind of syntax, that can express our rotation concisely, that can then be compiled into something more manageable for the simulator to use. For example, I was considering was compiling the rotation into mini-action lists based on energy (0-100 would give 101 lists) but that seemed to have issues with energy cost modifiers but still is interesting.

The problem with Mew's java approach is that it severely limited who could actually develop the script, whereas many people come to this forum and ask questions or make suggestions involving the simc and/or Ovale script since it's much more readable.

Huh? Maybe I'm biased but Java is on the easier side to follow and it's well documented. *shrugs*

Java is not my first choice; I originally considered using Lua for my simulator but worried about native threading and the gui interface.

I though about using Javascript and went as far as to implement a working version of it (modern JREs include a Javascript runtime as part of javax.script), but it was ridiculously slow.

On the first launch, it needs to download a bunch of things. It should be much faster after the first launch, mine launches instantly, but I only have access to machines with SSD.

I still don't really trust NAND flash. Maybe I'm just old. More realistically I've written wear-leveling systems and that stuff scares the crap out of me.

The SimC importer has difficulty when importing the AoE script since it cannot figure out the /use_item for hand slot. If you replace the "something_something_grips" with "hands", it will work properly, but I don't have a target setting available so it will only AoE 1 target :p

This is something that (from experience) should be done sooner rather than later since it's a gigantic hassle to retrofit code to add support for it.

I haven't tested the Blizzard Import with weird realm names, possibly I need some url escaping. I also need to add the TW region.

There's not much to it since you can have the library do it for you. Can't be bothered grepping through your zip file to see what you do.

Code: Select all

import java.net.URI;
import java.net.URL;

...

    URI uri = new URI("http", null, mRegion + ".battle.net", 80, "/api/wow/character/" + mServer + "/" + mName, "fields=items,stats,talents,professions&locale=en", null);
    URL url = new URL(uri.toASCIIString());

Java is not my primary language so there are probably exceptions, errors, and edge cases I have overlooked.

Hey that's what I was saying all through out writing Mew. If the code looks like something a C programmer would write, it's because I am a C programmer.

Nope, http://raffy.antistupid.com/wow/catsim/Src2.zip

You should carve that out into separate packages. It's sort of hard to follow what goes where and what's the components of what in it's current state. ("You are in a directory of tiny files, all alike.")

I approve of the fact that one of your few comments in your main simulator has profanity in it.

You should consider using Commons Math since it has a lot of useful things, in particular org.apache.commons.math.stat.descriptive.SummaryStatistic and the PRNG routines (Don't use java.util.Random, since it sucks).

Looks about what I would expect otherwise.

[Leafkiller]

Yawning! How are you doing?

[Yawning]

Yawning! How are you doing?

Bored, but not bored enough to start playing WoW again. Depending on how certain things turn out, this may change to "extremely busy" in the not-so-distant future.