RogueCalc - Page 3

Feist-Mok · 06/11/08, 8:22 PM

Here's a vote in favor of a Webapp for the simple reason that not everyone is using the same platform. I love the Gear sheet because it works seemlessly on my Mac without any problems wheras the DPS sheets macros are perpetually half broken. Desktop apps, while not neccesarily platform bound by definition, are that much more likely to be.

Also, if I'm giving advice to a clueless rogue, it's a thousand times easier to point them to a website they can play with than telling them to download something - I think it's a big part of why maxdps.com, in spite of it's perpetually flawed results, is so popular - people are paranoid about downloading anything onto their computers, even a harmless excel file, much less an application.

• Aldriana · 06/11/08, 9:53 PM

I think the porting issues are probably solvable - Python certainly works everywhere, it'd just be a matter of being careful about what additional libraries one might be using. Frankly, when one is going for snazzy UI, browser compatibility issues are almost as much of a pain for webapps as OS compatibility is for desktop apps.

That said, your point about people not wanting to download stuff is probably valid... I'll have to think about it. But it does appear that I'll be working on modeling for the next few weeks, which means this decision can be postponed a while.

CoroHD · 06/12/08, 3:53 AM

I'm either not cool enough to upload attachments, or I'm an idiot and can't find where to do so.

http://img441.imageshack.us/img441/6945/picture1ek5.png

Log:

Traceback (most recent call last):
  File "RogueCalc.py", line 73, in <module>
    printSummary(talents, gear, race, buffs)
  File "RogueCalc.py", line 31, in printSummary
    dps = dps_estimate(snd_size, rupture_size, talents, gear, race, buffs, constants)
  File "./lib/calcs/damage.py", line 251, in dps_estimate
    if gear.sso_neck and faction == 'Aldor':
NameError: global name 'faction' is not defined

Config:

[General]

# Specify your region (US or EU), your character name, and your realm name.
region = US
character = Corohd
realm = Illidan

# You may either use the talents downloaded from the armory, or the talents
# specified further down in this configuration file.  Enter either "armory"
# or "config" to specify your choice.
talent_source = armory

# Specify the amount of armor the target has, as an integer.  Recommended values
# are either 7685 or 6200
target_armor = 7685

# Specify Aldor or Scryers.
faction = Aldor


[Buffs]
# Enter your buffs here.  Pay close attention to the listed format restrictions, or things
# will break.


# Draenei racial.  Enter True or False.
heroic_presence = False


###############
# Druid Buffs #
###############

# Gift of the Wild.  Enter True or False.
gift_of_the_wild = True

# Faerie Fire.  Enter True or False.
faerie_fire = True

## Balance

# Improved Faerie Fire.  Enter the number of ranks possessed, from 0 to 3.
imp_faerie_fire = 0

## Feral

# Leader of the Pack.  Enter True or False.
leader_of_the_pack = True

# Mangle.  Enter True or False
mangle = True

## Restoration
# Improved Gift of the Wild.  Enter the number of ranks possessed, from 0 to 5.
imp_gotw = 5


################
# Hunter Buffs #
################

## Marksmanship

# Improved Hunter's Mark.  If Hunter's Mark is on the target, enter the number of ranks
# in Improved Hunter's Mark that the hunter has, from 0 to 5.
imp_hunters_mark = 5

# Trueshot Aura.  Enter True or False.
trueshot_aura = False

## Survival

# Expose Weakness.  Enter True or False to indicate whether or not the buff is up.  If it is,
# also enter  the hunter's agility as an integer, and an uptime fraction
# between 0 and 1.  Recommended uptime for 3/3 Expose Weakness is .95.

expose_weakness = False
hunter_agility = 900
expose_weakness_uptime = .95

## Beast Mastery

# Ferocious Inspiration.  Enter the number of hunters in your group that have it.  It is assumed
# that they have all 3 points in it, because otherwise they'd be morons.  Value must be an integer.
ferocious_inspirations = 0


#################
# Paladin Buffs #
#################

# Blessing of Might.  Enter True or False.
blessing_of_might = True

## Protection
# Blessing of Kings.  Enter True or False.
blessing_of_kings = True

## Retribution
# Improved Blessing of Might.  Enter number of ranks, from 0 to 5.
imp_blessing_of_might = 5

# Improved Seal of the Crusader.  Enter number of ranks, from 0 to 3.
imp_seal_of_the_crusader = 0

# Improved Sanctity Aura.  Enter number of ranks, from 0 to 2.
imp_sanctity_aura = 0


################
# Priest Buffs #
################

## Shadow
# Misery.  Enter number of ranks, from 0 to 5.
misery = 5


###############
# Rogue Buffs #
###############

# Expose Armor.  Enter True or False.  If both this and Sunders are selected, the more
# powerful buff will be used.
expose_armor = False

## Assassination
# Improved Expose Armor.  Enter number of ranks, from 0 to 2.
imp_expose_armor = 2


################
# Shaman Buffs #
################

# Grace of Air.  Enter True or False for whether the totem is being used, and an
# uptime value between 0 and 1.  If it is the only totem being dropped, uptime 
# should be 1.  If it is being twisted, the recommended value is .85.
grace_of_air = False
grace_of_air_uptime = .85

# Strength of Earth.  Enter True or False for whether the totem is being used.
strength_of_earth = True

# Heroisms.  Enter the number of heroisms you receive each 10 minute period.
# Value must be an integer.
heroisms = 1

## Enhancement
# Enhancing Totems.  Enter number of ranks, from 0 to 2.
enhancing_totems = 2

# Improved Weapon Totems, aka imp WF.  Enter number of ranks, from 0 to 2.
improved_weapon_totems = 2

# Unleashed Rage.  Enter True or False.
unleashed_rage = True


#################
# Warlock Buffs #
#################

# Curse of Recklessness.  Enter True or False.
curse_of_recklessness = False


#################
# Warrior Buffs #
#################

# Sunder Armor.  Enter number of sunders applied to target, from 0 to 5.
# If both this and Expose Armor are selected, the more powerful buff will
# be used.
sunders = 5

# Battle Shout.  Enter True or False.
# Additionally, enter True or False for whether the battle shouting warrior is using Solarian's Sapphire.
battle_shout = True
solarian_sapphire = False

## Fury
# Improved Battle Shout.  Enter number of ranks, from 0 to 5.
imp_battle_shout = 5

## Arms
# Blood Frenzy.  Enter number of ranks, from 0 to 2.
blood_frenzy = 0


##############
# Food Buffs #
##############

# Hit food.  Enter True if you're using Spicy Hot Talbuk, False otherwise.
hit_food = True

# Agi food.  Enter True if you're using Warp Burger or Grilled Mudfish, False otherwise.
agi_food = False

# AP food.  Enter true if you're using Ravager Dog, False otherwise.
ap_food = False


################
# Elixir Buffs #
################

# Flask of Relentless Assault.  Enter True or False.
flask = True

# Elixir of Major Agility.  Enter True or False.
major_agi = False


################
# Scroll Buffs #
################

# Scroll of Agility V.  Enter True or False.
scroll_of_agi = False

# Scroll of Strength V.  Enter True or False.
scroll_of_str = False


###############
# Consumables #
###############

# Haste Pots.  Enter True if you're drinking them every cooldown, False otherwise.
haste_pots = False

# Drums.  Enter the number of people using drums of battle (haste drums) each cooldown.
drums_of_battle = 1

# Drums.  Enter the number of people using drums of war (ap drums) each cooldown.
drums_of_war = 0


######################
# Temporary Enchants #
######################

# Select which temporary enchant is being used on each hand.  Allowed values are None, wf, dp, and ip.
mh_temporary_enchant = wf
oh_temporary_enchant = dp




[Talents]

# Enter your talents here.  Do not change the name of any subject heading, or enter
# a talent value that is not an integer.

# Assassination Talents
malice = 5
ruthlessness = 3
murder = 2
imp_bs = 0
relentless_strikes = 1
lethality = 5
imp_poisons = 0
vile_poisons = 4
quick_recovery = 0
master_poisoner = 0

# Combat Talents        
imp_ss = 2
imp_snd = 3
precision = 5
dw_spec = 5
sword_spec = 5
dagger_spec = 0
mace_spec = 0
fist_spec = 0
blade_flurry = 1
weapon_expertise = 2
aggression = 3
vitality = 2
adrenaline_rush = 1
combat_potency = 5
surprise_attacks = 1

# Subtlety Talents        
opportunity = 0
serrated_blades = 0
dirty_deeds = 0
hemo = 0
deadliness = 0
sinister_calling = 0

• Aldriana · 06/12/08, 4:56 AM

Fixed. For those of you that may be playing with this at home, the only file that changed is /lib/calcs/constants.py

Re: attachments. Not sure if everyone can do it or not, but at least for me in the "Advanced Options" section of reply, under the "Miscellaneous Options" subsection, there's an "Attach Files" section.

drumbum · 06/12/08, 5:12 AM

Originally Posted by Aldriana

Re: attachments. Not sure if everyone can do it or not, but at least for me in the "Advanced Options" section of reply, under the "Miscellaneous Options" subsection, there's an "Attach Files" section.

Only "privileged" users may attach files. I'm not sure what the exact requirements are, but I just know that I can't attach files either.

• Vulajin · 06/12/08, 5:27 AM

Originally Posted by drumbum

Only "privileged" users may attach files. I'm not sure what the exact requirements are, but I just know that I can't attach files either.

You must be a Benefactor. User CP > Miscellaneous > Paid Subscriptions.

• Aldriana · 06/12/08, 5:41 AM

I'm actually not a benefactor... must've picked it up from being a TTT editor or some such. Well, whatever. Posting the relevant information in [code] blocks will work just fine for those that can't attach files.

Clinch · 06/12/08, 4:09 PM

I was poking around the Python code and managed to get a basic Armory XML fetcher working (thought it would be useful to be able to select slot items from the Armory rather than a pre-populated dropdown), and thought, 'Hey - maybe someone's done this already!'.

First Google search yielded:

chardev.org - A World of Warcraft character planner v.3.a

Seems to be all Javascript, with AJAX Armory queries by slot. Something like this would be a great platform to display gear/talents/buffs, and the 'click slot/select item' would make looking for upgrades for a slot or checking different enchants so easy.

♦ pewsey · 06/12/08, 8:45 PM

Wonderful work Aldriana.

Couple of comments.

I'd like;

RogueCalc -fetch pewsey -outputdir /saved
RogueCalc -copy pewsey -dest pewsey_t6 -outputdir /saved
(edit the saved version with a text editor)

RogueCalc -analyse all -outputdir /saved

or

RogueCalc -analyse pewsey -outputdir /saved

Why ?

Fetching my riding crop is kinda sad. Fetching from the Armory every time is really sad.
Being able to create different versions based on my current gear is win (for trinket swapping)

Now,

I also want to be able to specify different versions of RogueCalcConfig so I can see the effect of lack of FF, different food buffs, different group compositions. This could be done by either specifying new config files like above, or by providing override values on the command line.

RogueCalc.py -combatVars ImpFF=true;Food=SpicyHotTalbuk

I _don't_ want a snazzy UI. In fact, I'd love it to never have a UI at all and just edit text files. Saving the fetched armory in a neutral domain version of the character would be wonderful (XML is not terrible for this purpose)

The most appropriate way to do this is to separate the "getting the data" and "running the analysis" so that people can create funky UIs for those people who want them, and people like me can build up comprehensive scripting frameworks to analyse tiny changes in the input parameters across a wide variety of configurations.

scrivtastic · 06/12/08, 9:09 PM

Thing 1: Bravo! This is fantastic, and I am overjoyed that you have taken the time to do this. I am a developer by day, and I can appreciate the hard work and head-scratching that goes into a program of this complexity.

Thing 2: Being that my experience in various scripting languages and type languages is limited to php/c and java/coldfusion, I can't answer this definitively, but isn't it within the realm of possibility to re-create this functionality from within the LUA framework? While I think a web app is superior to a local python app, a LUA app that I can use without leaving the environs of the game would be even better yet. On going to the lua.org site, it describes the basic language as "simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping." Is there anyone with LUA experience that can comment?

• Aldriana · 06/12/08, 9:40 PM

Re: scrivtastic's comments:
I don't personally have any LUA experience, but from what I've been told it's fairly similar to python so writing an equivalent of this in it should be within the realm of possibility. However, as I *don't* have any LUA experience, it would slow me down significantly to try to write this in an unfamilar language rather than one I know well, so I'm disinclined to try to do so myself; moreover, while it would be nifty to have an in-game mod with dynamically calculated EP values and the like, I think most people do quite a bit of their theorycrafting while not actively playing the game, so in a lot of ways I think the web/desktop app approach is superior to the in-game mod. For these reasons, I'm not going to worry about it too much at this stage.

That said: the best approach for tying into a WoW mod would probably be to investigate what's possible in terms of calling into other languages and/or making web services calls; if such things are possible, it would be quite reasonable to write a LUA app that simply calls into the RogueCalc API to get what it needs.

Re: Pewsey's comments:
I'm in the process of doing some additional refactoring that should make that a little more doable - I'm trying to get the framework organized to be as modular as possible for maximal ease of development by multiple individuals. Once that's done, however, consensus seemed to be that I should work on modeling first, so anything that I don't get for free during the refactoring will need to wait until either a) I finish the modeling stuff or b) someone else gets around to doing it.

So, short version: probably sometime over the weekend I'll be releasing something with some limited ability to save and load profiles. It will probably be horrifically non-user friendly (probably involving entering raw item codes), but it should be possible for a determined user to make the sorts of changes you have in mind. More sophisticated command line options, however, are still probably a ways off.

• Shalas · 06/12/08, 10:22 PM

Originally Posted by Aldriana

That said: the best approach for tying into a WoW mod would probably be to investigate what's possible in terms of calling into other languages and/or making web services calls; if such things are possible, it would be quite reasonable to write a LUA app that simply calls into the RogueCalc API to get what it needs.

By design, absolutely nothing short of generating lua files while WoW is not running is possible. There's only one way to communicate with external programs left that doesn't violate the ToS, and it's very impractical.

• Aldriana · 06/12/08, 10:36 PM

That's... unfortunate. Sounds like there will be no mod version of this, then.

koaschten · 06/13/08, 6:30 AM

Uuuh i dont seeh a problem there, if someone ever should port this to lua, you could just make an ingame mod from it, pulling data... lo and behold ... from your char screen.
edit: To clarify, you could simply generate a lootrank link ingame then to copy paste for possible upgrades and probably even change slots by itemid, as you can call items you dont possess via itemid's ingame if they are known.

Aldriana, entering raw item id's to generate different "offline" profiles is absolutely fine, considering they are in the URL at any itemdb page anyway as the unique descriptor and you wouldnt have to get so many IDs anyway when optimizing gear... i prefer ID's anyway, they are not language centered

Something that is bugging me though... alpha talents. But not so much at the moment

• Aldriana · 06/13/08, 6:55 AM

Sure, you could rewrite the whole thing in LUA. But that's a lot of sophisticated logic to carry over, and I for one have no interest in trying to maintain two separate codebases. But if someone wants to be responsible for the LUA version, that's doesn't bother me any.

Regarding expansion talents: I've started to think about them a bit, but I suspect they're still sufficiently subject to change that I'm not going to worry excessively about getting them in here yet. I posted some preliminary thoughts on them in the PvE DPS/WotLK thread.

scrivtastic · 06/13/08, 12:25 PM

Good points Aldriana. I suppose the major theorycrafting moments that happen (for me) have usually been decided upon well before a talent change is done or a particular item is purchased/dropped.

In reality, the only time that I think in-game information really matters to me is when I get results that say something, but there is a discrepancy with what I think I should be getting, and what I am actually seeing.

It might be interesting to have python export some data/config files (most likely XML) that could interact with a separate LUA mod that actually parsed both your combat log and the exported files. That way, you could do your theorycrafting, come up with results that you think you should have, and then consult your in-game mod after certain events to see how close you are to achieving "optimum".

It might seem kind of silly, but I pride myself on seeing my name as #1 on any dps charts for any group/raid that I am ever in. When I am not #1, I want to know why!

Artres · 06/13/08, 4:49 PM

First I would like to say thank you Aldriana for creating this. I have some programming knowledge and have been thinking of creating something similar with friends but my knowledge is not upto par.

I have run the program using a few rogues in guild and a few rogues from other guilds and noticed that whenever I enter a horde name (Ashlea, Robotron) I get errors.

Tracebark <most recent call last>:
    File "C:\Documents and Settings\RogueCalc.py", Line 1349, in <module>
          talents.set_from_armory<name,realm,region>
    File "C:\Documents and Settings\RogueCalc.py", Line 292, in set_from_armory
          self.sinister_calling = int(subTalents[20])
IndexError: String index out of range

appears after using Ashlea; After using Robotron I get Error reading talents from armory; Your profile may be down.

The working names I used were Artres, Keichii, Postmortum, and Hendoskillz

Safiyania · 06/13/08, 7:43 PM

Given that the Armory can sometimes be slow to respond, and I've had my profile fail to load more than a few times, I'd suspect that your issues are more likely Armory-side than RogueCalc specific.

On another note, given discussion from the WotLK thread regarding rogue spec changes, I would say there is now an even stronger need to work on Seal Fate type rotation modelling as it would appear that Blizz is moving to push us back to dagger use (not that I mind that at all). Although this is highly presumptive at this point since we are only talking about Alpha stage changes, I would say that it still stands to reason that cycle modelling should be the primary focus of RogueCalc development and not UI and Item Database refinement. Of course I have about as much programming ability as Britney Spears has sanity so spend my two cents where you please.

Capek · 06/13/08, 10:49 PM

The only reason I would want to see anything like this in game would be to see a 'possible dps' vs 'actual dps' realtime report based on the buffs you have going into a fight, the debuffs actually used on the boss and the uptime of both. On progression fights we will always lose someone that would otherwise bolster our dps (Our warrior in particular is quite a kamikaze and we go half a fight with him eating dust sometimes).

On reflection this would probably be better based on a combat log after than in game...and I am talking a bit off topic so I'll leave it there.

• Aldriana · 06/14/08, 12:07 AM

Well, honestly, that's sort of an interesting problem in it's own right - my friend and I have discussed any number of times the notion of making a "suck calculator". Basically, a program that you upload combat logs into, and it tells you how much you do or don't suck - or, more specifically, what you're doing right, what you're doing wrong, and some sort of rating of your overall performance. The problem is, I don't think there's quite enough information available in the combat log to do this right (like, detecting energy capping would be a royal pain), so I'm not sure how practical an undertaking it would actually be. But it's definitely an interesting idea.

Shaker · 06/14/08, 1:59 AM

Well, one metric to describe energy capping is just "Energy generated during combat" vs "Energy spent during combat" and having a utilization percentage be your metric. Obviously some fights would be horrible with this sort of analysis, but honestly, those types of fights are going to be bad for combat log analysis anyway, you'd want to use Brut/Teron logs primarily.

dedmonwakeen · 06/14/08, 8:27 PM

Originally Posted by Aldriana

The fundamental issue with simulators is that while they're useful for certain types of questions - damage estimates, spec comparisons, possibly cycle comparison - they're really, really, *really* bad at others - notably computing EP weights. It takes an *incredibly* long time to get even remotely useful EP values from a simulator, such that you're generally better off with even an imperfect model than you are with a perfectly accurate simulation.

The "incredibly long time" assertion is statement of performance....... which in turn is a statement of code language and programming skill.

SimulationCraft is a multi-player caster-dps simulator that runs at about 100,000 times faster than WoW "real life", plenty fast enough for making "delta adjusts" to gear to see how they scale.

I've just re-architected the core engine to support physical-dps classes and I'm about to start implementing the class-specific modules shortly.

• Aldriana · 06/14/08, 8:41 PM

Sure. Problem is, even at 100,000x realtime, it *still* takes a long time. Consider:

Lets say we want EP that are good to, say, 5%. In reality we might want them better than that, but lets say for the moment that 5% is good enough. Well, to do so, we need to know the damage benefit of each stat to within 3.5%. So, for instance, to compute the value of 1 AP - which is around .4 DPS - you need to know how much damage it gives to within .014 DPS. And to do that, we need to know the damage done for a given gear set to .01 DPS.

Now, I don't know exactly what the variance on these things actually look like, but I'd be willing to bet that the variance on Brutallus is at least 50 DPS; hence, we need a factor of 5000 more accuracy, which takes 25 million times longer, which is about 150 million minutes. At 100k times faster than realtime, it thus takes about a day to get each DPS number, and there's about 15 different computations to do to get all the major EP. Hence, we're talking something on the order of a 2 weeks of continuous operation at 100000x realtime speed to get decent EP values.

Now, there are some optimizations you can make for improved accuracy - taking larger ranges and dividing, and the like. But those introduce inaccuracies in their own right, and don't work for all stats. So at the very least I suspect we're still talking a week for good numbers - which just isn't practical. To be even remotely useful, you'd need to be 100 *million* times faster than realtime, and a billion would be better.

Long story short: simulators may be fast. They're nowhere near fast enough to do EP well. And for that reason, I'm going to stick with my calculator, thanks.

dedmonwakeen · 06/14/08, 11:25 PM

Originally Posted by Aldriana

Long story short: simulators may be fast. They're nowhere near fast enough to do EP well. And for that reason, I'm going to stick with my calculator, thanks.

Despite my personal investment in simulation efforts, I'm a fan of both formulation and simulation. They each have their strengths and I've had numerous enjoyable conversations on these boards comparing the two. Over time I have come to the following, possibly too simplistic, conclusion:

The accuracy of formulation relies upon our ability to accurately translate proc-based models into closed form solutions.
The accuracy of simulation relies upon our ability to reduce variance and make it run freakishly fast.

It has been been my experience that simply averaging min/max base weapon/spell damage goes a long way to reduce the variance. Using a language like C++ compiled and optimized for a particular micro-architecture delivers exceptional performance.

As you stated, simulation accuracy depends upon the number of iterations. The question that remains: How many iterations are required to achieve an accuracy on par with (or exceed that of) a comparable formulation?

Bottom line: If simulation can't exceed formulation accuracy significantly and do it in less than a minute, it just isn't worth it. Formulation can be delivered in a spreadsheet. Good simulators, on the other hand, are compiled desktop apps with a bajillion options and notoriously bad user interfaces.

But sometimes........ sometimes........ sometimes you can get the variance under control...... sometimes the formulation just can't handle the multi-layer proc synergy....... sometimes you have the horsepower to get the job done.

But most of the time a simple spreadsheet is all you need.

Erg.... This is your thread for discussing an excellent tool...... So if I have offended or unnecessarily derailed the thread, please except my apologies.

• Aldriana · 06/15/08, 3:42 AM

I don't mean to knock simulators; as I've said, they certainly have their place, and I'm by no means attempting to discourage anyone who happens to feel like writing one from doing so. I think a really good simulator would be a powerful tool in terms of assessing the quality of our various approximations and validating the various spreadsheets and calculators. It's just not something I feel like working on - at least not right now.

Now, it's true that spreadsheets have their place, and so far they've done a fairly admirable job in filling our needs; but I don't think most people appreciate what an utter pain it is to maintain a really accurate spreadsheet, how cumbersome the format is, and how many shortcomings they really do have. They're fine for what they are, but it's really an inefficient medium for what we're trying to do.

It is my belief that many of these problems can be eliminated by doing a similar sort of analysis that the spreadsheets do, but doing it in a programming language instead. Platform and spreadsheet program issues vanish. New gear is added automatically. All calculations can use the same computation function rather than every formula needing to be duplicated dozens if not hundreds of times. It's easier to maintain, easier to use (eventually, anyway), and more accurate than a spreadsheet ever can be.

It's basically the same thing I did with the Rogue Gear Spreadsheet. At the time I started on it., the DPS sheet, while having been a great tool for a long time, was no longer adequate for the new effects that were being added in the expansion. The framework it had in place was not adequate for what we were doing, so I set about writing a new framework that was. In the 15 months since then, both spreadsheets have matured incredibly, and are now both capable tools for modeling the problems of the current expansion...

...but the writing is on the wall. With the coming of the next expansion, the same problems that arose then will arise again. There will be new effects beyond the scope of the current spreadsheets, and while we could go through the painful process of upgrading them, I expect we will be happier in the long run by writing a new, better framework that is much more able to accommodate changes - hence, this is what I'm doing. It's not that this is going to do anything that we haven't been doing with spreadsheets - it's just going to do it better. Or at least, that's the plan.