I added Might of the Scourge, fixed the Heartrazor bug, and did some assorted other cleanup; I also tweaked the output a bit so it lists only the top 5 cycles, but also gives EP values for the major stats (though it doesn't handle the hit/expertise caps correctly). I also added some error handling for the most common issues, and set it up to log debug information to the file RogueCalc.log. If you run across an error in the operation of this program, I may ask to see your log file in addition to the console output and the config file.
Note: only the python program has changed here, so if you want to keep your existing config file and just update the RogueCalc.py file, that will work.
Am I correct in assuming that when the sheet lists an Expertise EP of 0 it is because the rogue in question is capped? I get that result on human rogues with Shard of Contempt atm, but not on most others.
Also, thank you for what is the beginnings of what I can only expect to be an awesome tool as we move into uncharted territory w/ the expansion - I can only see this getting better and better and surpassing the spreadsheets in acuracy, effectiveness, and ease of use (Excel is, at the end of the day, quite a pita).
Yes, as mentioned, it doesn't pick up the hit or expertise caps correctly so just sets the stat value to zero. I have some ideas for how to fix that, I just haven't had time to work on it. I'd like to at least get things to the point where you can use this to fill in Lootrank and hence get some decent loot recommendations out of it, allbeit indirectly.
Also, I'm starting to think that some UI to turn this into a desktop app rather than a command line tool is going to be pretty necessary before we go too much further, so I think I'm probably going to be focusing on that in the coming days and weeks.
It uses the default buffs and doesn't have options to change them, and this only goes off Armory at this time, but I also added a Lootrank link so that you can quickly assess item values with your current EP values.
It uses the default buffs and doesn't have options to change them, and this only goes off Armory at this time, but I also added a Lootrank link so that you can quickly assess item values with your current EP values.
Thanks Shaker, was about to do that
And thanks Aldriana, will definitely have a look at this, the Excel sheet always greatly turned me off.
Something I find strange :
The RogueCalc says around 1200dps for my 41/20 Mut spec, but from what I've seen in the code its a calculation from BS.
The spreadsheet tells me (for the same buffs) around 1400dps.
The difference seems minimal for such a talent gap ...
It uses the default buffs and doesn't have options to change them, and this only goes off Armory at this time, but I also added a Lootrank link so that you can quickly assess item values with your current EP values.
Thankyou, was waiting for something like this to be put up.
Thankyou to Aldriana as well. Its a good tool to add to my theory crafting arsenal.
Just want to say I've been playing around with this since last night, and you've done an awesome job. I think this will be an incredible tool for the Rogue community.
I do have one small request though -- Can we have an option to toggle the 5 cycle limit on/off. For comparison purposes it would be cool to see all of them again once this gets into later development.
(Edit)
I'll keep playing around with it and give more (Hopefully useful) feedback.
1) Regarding the many armory profiles that are down, would it be possible to fall back on a site like Armory Lite - Information, Simplified. that has lots of cached profiles?
2) In order for this to hope to replace the spreadsheet for me, I don't need reccomendations, but I do need the ability to replace a piece of gear I'm wearing in the armory with something else to find out whether it's worth bothering to use - EP values are fine for determining whether a regem will help or straight stat changes, but when you factor in set bonus values and procs, some pieces just cannot be compared without actually 'equipping' them in the spreadsheet, or, hopefully soon in roguecalc.
Chariu/Spoon: Yes, special characters will probably cause problems. For the initial release I just through some quick parsing in front of the underlying calculator - I didn't stop and think through all the special cases. I'll have to look into how the armory handles such characters.
WoWArmory seems to use UTF-8 url encoding, and not the standard ASCII url encoding.
So, having thought about the problem a bit more over the last day or so, I can think of several reasonable ways to proceed, all of which are important things that we'll want to be able to do eventually, but all of which take time. Hence, the question is one of prioritization. Hence, my question to community is: which of the following are you most interested in seeing added next?
1. More detailed outputs
Right now we're displaying the top couple of cycles and a few EP weights (some of which have problems with caps). One thing that could be changed is giving the option to display more or less cycles, EP weights for weapon speed and weapon damage, and so on. Basically, get it to the point where everything you could possibly want to know is displayed, and with a very simply UI like the one Shaker posted, it could generate a fully-populated, totally-accurate Lootrank for you.
2. More detailed inputs
Right now, your only gear input is armory fetch. It would be nice if you could, for instance, change out items, save configurations to use while the armory is down, and so forth. Note, however, that there wouldn't be a GUI for this; you'd have to enter your gear in the config file or some such, either by item id or (possibly) by name... which isn't exactly the nicest way to do so.
3. Better UI
Basically, shortcut the problems with 1 and 2 by writing the UI for them first; rather than having this be an increasingly complicated set of desktop tools, build it out into an application where there are dropdowns and checkboxes and search fields and all manner of such niftiness to make input and output much easier and more painless. Functionality would stay where it is until the UI work is done - then we could start looking more into doing the other items on this list.
4. Better modeling
I had an idea last night for how to address the dagger-related issues of this sheet once and for all, namely: I think I've figured out a way to do damage estimates for more-or-less general cycles. Whereas at the moment the sheet only does cycles of the form XsYr, I think it should be possible to come up with a way of estimating damage for a more-or-less arbitrary cycle. If you want to know the damage for 5s? No problem. If you want to know the damage for 3s4r3n3r5s2e1s? We can do that too. And perhaps best of all, the methods for so doing should also allow the tool to extend to Mutilate and Seal Fate cycles, which we currently can't handle at all.
As a related question, as the goal is an application of some point, do people have a preference as to whether this becomes a desktop application or a webapp? That is, would you rather have a program that you can download to your computer and use there, or would you rather have roguecalc.com, a website with (roughly) the same functionality?
Note that all these questions assume that I'm going to wind up doing most of the work myself; when and if other people start to get involved, it may become possible to work on more of these problems at once. But until that happens, I do need to prioritize these things, and this is your chance to provide feedback on what you'd like to see.
Absolutely the most important by far is number 4. Consider that we are currently in the "no man's land" between BC and Wrath, where there isn't really a lot of need for a more accessible theorycrafting tool just yet. The Gear Spreadsheet already fulfills that purpose very well, and will do so until Wrath renders it obsolete. At that time, having a good UI and input/output options will be very important. However, right now the best thing to do is to build up a foundation that is well-equipped to handle anything that might come our way in terms of theorycrafting developments. Getting started on such a thing right now will allow you to build all of the input/output options and the UI around a fully-featured model, rather than having to tack stuff on later.
Well, I think that's definitely where Ald's talents lie - if the model can accept itemID inputs, at that point we might want to break out the backend seperate from the frontend - I can doll up the UI to be more functional (if only just a dropdown with itemIDs that allow you to select gear), add in the ability to import a spec from a worldofwarcraft.com string (the 0000000000050502301204053023210) thing, or add dropdowns to the frontend for spec as well, and I think we have the basics so that development can take place in tandem along multiple paths.
Just in full disclosure though, I'm leading a raid guild, and planning a wedding, so while I have the ability and the desire to do a lot of these tasks, time isn't something I have a ton of. However, I'm very interested in this project, and would love to help as much as possible. I have a pretty reasonable hosting plan and can donate time/space for this as well if it goes towards the web as a direction.
I was initially thinking of solving the hosting problem for the webapp route via Google App Engine, but if people have spare bandwith for hosting this that's certainly an option as well.
As to the rest: yeah, better separation of code is definitely something that's needed; I wrote the actual brains of this thing first with everything reading from hard-coded values in the program; once I finished that (which was last Friday evening) I realized that I needed an interface that didn't require people to add up their stats by hand and then set a whole mess of variables inside the program, so I whipped up the most rudimentary UI imaginable in tossed that in as a front-end so people could play with it (which, you'll note, was completed in less than 48 hours during which time I did any number of other things). So, yeah, while the internal structure of the computation functions may not be great, there was at least some time spent into making the architecture vaguely sensible; this cannot be said of the UI, which I freely acknowledge is crap. I'm fully capable of something better - it's just that I was going for getting something up and running fast rather than good design. So as soon as there are other people wanting to work on this, some time will need to be devoted into breaking things up into more sensible pieces.
Of course, if we were really serious about having multiple people working on this, we should also set up version control (Subversion or the like) and possibly bug tracking as well. But I don't think we need that level of organization quite yet.
The point is valid, though; there are probably more people around here with some programming experience that can work out some of the item parsing/UI/etc. type problems than there are people with experience writing in-depth models of rogue DPS, so it may well make more sense for me to work on the latter.
Yeah, I fully agree. I'm near-certain I have some form of version control on my host, and my current usage for bandwidth/disk are as follows:
Your Account Provides:
695.77 GB Disk (Grows 2 GB / week)
Used: 6 GB (0.8%)
8.79 TB BW per Cycle (Grows 40 GB / week)
Used this Cycle: 845.7 MB (0.0%)
So unless this project outgrows either those limits or there's other technical issues with my space (programs needed/performance issues), I'm aboslutely willing to host it and give a few select people access to do what they need to with it. I'm paying for the space for my guild already so other than a possible domain name at roughly $10/yr, it'd be zero impact on me.
Thanks for the new tool, Aldriana - gave the code and config a quick look, nice and clean, and best of all, self-documenting for the most part.
I ran it with no problems (seemed low compared to the spreadsheet, though I may be in PvP gear, I can confirm this later) after adding the path to the Python executable to my 'Path' Environment variable. I didn't see instructions for this in the first post, and the Python Windows binary installer didn't do it for me, so I'll lay it out here if you feel the need to add it to the install instructions.
0. Install the Python Windows binary.
1. Right-click on the 'Computer' icon on the Desktop, or open Control Panel -> System.
2. Choose 'Advanced System Settings from the side menu.
3. Click the 'Environment Variables' button near the bottom of the dialog box that appears.
4. From the 'System variables' section (The lower box), find the 'Path' entry, click on it to select it, then click 'Edit'.
5. Add a semicolon ( ; ) after the last entry, then add 'C:\Python25' (Default, use the path to your install directory if different).
6. Click 'OK' for the open dialogs and close any Command Prompt windows.
7. Verify that Python is accessible from the command line by opening a Command Prompt (from anywhere) and typing 'python' - you should be taken into the Python shell, type exit() to exit the Python shell.
Python files (.py extension) should now be executable from any location.
Had you considered using Javascript to do the modelling? I don't think its XML handling is on par with Python/Java/PHP, but it's totally client-side, and easily hooked up to web services via AJAX. You could also provide a very slick frontend with it, I'm envisioning the modeling engine hooked up to a wowhead-quality view of your character sheet (populated from the armory), with upgrades available at the click of the mouse.
I'd be willing to help with any QA or web dev that you'd like to see done, cheers for the hard work.
Last edited by Clinch : 06/11/08 at 4:50 PM.
Reason: Spacing to avoid emoticons.
On the general topic of analysis and theorycrafting software, how useful would a real simulator be? I wrote 90% of a decent Fury Warrior simulator in python back in the BWL era, and ever since I've had a lot of ideas about how to Do It Right, but not so much the time or a reason to actually do it. The kind of output you'd get would basically be a WWS wet dream - breakdowns every which way. The hard part of actually using a simulator is generating inputs for it, which in this case would be which abilities to use under which circumstances. I had some vague ideas about decision trees and finite state machines to find "optimal" cycles, but that's really a completely separate project from the simulator itself.
4. Better modeling
I had an idea last night for how to address the dagger-related issues of this sheet once and for all, namely: I think I've figured out a way to do damage estimates for more-or-less general cycles. Whereas at the moment the sheet only does cycles of the form XsYr, I think it should be possible to come up with a way of estimating damage for a more-or-less arbitrary cycle. If you want to know the damage for 5s? No problem. If you want to know the damage for 3s4r3n3r5s2e1s? We can do that too. And perhaps best of all, the methods for so doing should also allow the tool to extend to Mutilate and Seal Fate cycles, which we currently can't handle at all.
This is what I am most interested in. In fact, what I really want to see is a good method for adapting to and modeling variability within cycles based on a ruleset. This is something that I really feel isn't adequately captured right now in the DPS sheet with regard to Mutilate cycles, and I'm the one who wrote those cycles. After all, there is a big difference between the cycle time for using 1 mutilate and using 2 mutilates, and saying it takes "1.5" mutilates to achieve the average cycle is... awkward. So even though I think we have a decent model, I really think it would be a lot better in a program form, and I'd be very interested to see what you have.
Originally Posted by Aldriana
As a related question, as the goal is an application of some point, do people have a preference as to whether this becomes a desktop application or a webapp? That is, would you rather have a program that you can download to your computer and use there, or would you rather have roguecalc.com, a website with (roughly) the same functionality?
Either/or. I kinda like webapps, actually, as it opens a lot of potential for integrating directly into, say, the Wowhead database, or similar. Using Wowhead's item database would save you a lot of time compiling your own, with the disadvantage being (of course) that when Wowhead is down so is your app.
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.
So, what might be worthwhile is to have a very good simulator on hand as sort of a sanity pass on the model, to make sure that your answers are in the right ballpark... but as you need the calculator either way, that's the side of things that I'm more interested in for the moment.
Regarding javascript: I don't have as much expertise with it, so I could be wrong, but my sense is that it tends to be inferior for a lot of the things I want to do. It's very good at doing UI optimizations and such, and if we go the webapp route there will certainly be javascript involved in the UI side of things... but in terms of actually doing all the modeling, I think it would be somewhat inefficient. At the moment, if we go the webapp direction, my plan would be to write the guts of it in Django, with Javascript in the templates to get the optimal user experience.
That said: it's not at all clear to me that we wouldn't be better off making a desktop app... I guess it really comes down to which one we can find more people to help with. I'm currently working on refactoring things a bit, with the idea being that I can then focus only on those files and functions that effect the modeling, which can then be plugged in to any number of front ends (command line, webapp, desktop app, whatever).
Edit: Speaking a little bit more about the webapp vs desktop app piece:
Either way, I suspect we're going to wind up leveraging wowhead or a similar site for the items list. I suspect either way you work it, you write a script somewhere that fetches an item list from wowhead and shoves it into a database (for a desktop app, this would just be SQLite; in a webapp you'd probably want to use a real database like MySQL or PostgreSQL. All item queries are then made against this database.
The difference comes in updating this. A webapp would probably have a function that automatically runs, say, once an hour (or once a day, or whatever), scrubs wowhead for new items, and loads any it finds into the database; the desktop app would have the same function, but would probably need to be run manually (i.e., there a button or menu option somewhere called "update item database").
The difference as I see it is that a desktop app will probably have a few more manual steps involved in using it (such as the need to update your item database), while a webapp slightly complicates the ability to save item sets and the like (as you need a provision for users to log in and bind saved settings to their account). It also requires significantly more heavy-duty hosting, as all the data and all the calculations are server-side.
I think either can be made to work, and at this stage it doesn't matter a whole lot; but by the time we start adding GUI to this stuff, we'll need to decide which way we're going to go.
Yeah, I think Left touched on what I see as the strength of simulators - exploring and comparing conditional cycles and procs that are tough to model. I actually wrote the Fury Warrior sim in the first place because I was curious about their 'feedback loop' and the ramping-up effect that people described. Once a model is built, it can answer the same questions a simulator could, but much faster.
Right. Personally, I don't see any fundamental reason why what Left's suggesting couldn't be done in a calculator... it's just an *incredibly* large amount of work, since it basically works out to a bunch of casework on a massive scale. I actually started working on such a thing once but decided it wasn't high enough on my priority list that I felt like finishing it. What I have in mind will still be relatively average-based, but I think it will still probably be at least as accurate as any of the existing modeling methods, and hence worthwhile. But, again, if you want to write a supplemental simulator for inclusion, that's fine by me.
One more vote in favor of improved modelling being a top focus. I love playing around with Mutilate and have always regretted that assuch I haven't been able to use that great tools you've put together, and these days palying Mut in a raid, while not theorectically optimal, isn't *that* far-fetched. One area in particular that's not captured by the spreadsheets and which affects Mutilate particularly strongly is energy queueing. Right now the DPS spreadsheet models for Mut assume that the damage boost from FW and AToL are proportional to the uptime of the buffs, but in reality a good Mutilate rogue will make sure that Mut is always inside FW and Rupture almost always is. Good modelling for energy queueing probably has some benefits for combat, but I imagine the difference isn't as signficant there. Anyway, just another thing that's not really captured by spreadsheets, but which may be much more feasible to examine with a desktop or web app.
Found a few bugs and fixed them - the major one being that crit rating and haste rating from buffs wasn't getting picked up correctly. That should now be fixed. The major difference is just internal refactoring to make it easier to work with - for those of you who have looked at the internal workings, I've renamed the Stats object - it's now a Gear object, which should make it more clear what it's doing. I've also refactored the code a bit such that functions that do fundamentally different things are in different files, which should make parallel development a little more feasible.
In terms of installing: the package now contains three things, a new version of RogueCalc.py, a folder of support functions named lib, and the config file. Config file format still hasn't changed, so you're still free to keep using your existing config file(s); the lib folder and RogueCalc.py files are the new brains of the operation, and replace the previous RogueCalc.py file.
06/09/08, 9:00 PM
in 
