Perhaps the most valuable thing right now would be a CSS person.
I actually got a PM from someone in the last few days with some CSS/HTML experience - as soon as I get caught up on all the other things I'm working on, I'll be sending out additional coordination information to everyone who has expressed interest (so if you've PMed/Emailed me and haven't gotten a response, it's not that I'm ignoring you - I've just been busy).
I think the initial hurdle moving forward is going to be in terms of coordination - I've now had almost a dozen different people express interest, so the first thing we need to do is decide what we want to build and divide up the work. I've had a number of interesting conversations with some of you already, and I know there are some good ideas out there - it's just a matter of putting them all together.
So, in brief: we are in the process of ramping up on this project, but it will take time. The tentative goal I have for myself is to get something usable around the start of the new year, but don't take that as in any way a commitment - it all depends on how much time I - and the other people on the project - have to work on it.
So I'm not that familiar with Python but I am a PHP developer, If I can get enough of the Python syntax down would you have any grievances if I were to convert this tool into a PHP, web based program for ease of use? I wanted to make an online tool for rogues for a little while now, I've been looking at the excel sheets to calculate the data and thinking of how I could present this in a clean, easy to use way. I have a few ideas in mind using an AJAX style armory import... The current issue I'm having is the armory "lock-out" that the armory issues a website when you request from it too much using CURL.
If you'll note the roadmap that has been included in my last couple posts, turning this into a web-based program for ease of use is one of the major things we're planning to do in the coming months. I'd happily listen to any ideas you have in terms of UI and features (and anything else, for that matter), but it seems sort of unnecessary for you to build your own thing when it would be fairly redundant with what's currently being planned.
So I'm not that familiar with Python but I am a PHP developer, If I can get enough of the Python syntax down would you have any grievances if I were to convert this tool into a PHP, web based program for ease of use? I wanted to make an online tool for rogues for a little while now, I've been looking at the excel sheets to calculate the data and thinking of how I could present this in a clean, easy to use way. I have a few ideas in mind using an AJAX style armory import... The current issue I'm having is the armory "lock-out" that the armory issues a website when you request from it too much using CURL.
You can do the armory lookups in serverside PHP the first time an item is spotted and save them locally to your server, then just do client side requests to your server's XML files, i.e check filemtime to decide new item updates, should require minimal developer maintenance when new instances are released. Some clever developer pre-caching of the most popular items, and some randomness added to the item update times, should keep the amount of requests per day down. Worst case you could just do the item updates manually and not import items based on the character gear, i.e show a N/A for unknown items. I've done some light testing with Google Web Toolkit client side (Develop in Java, compile to JavaScript) for simulations and some simple PHP server side for armory imports of items (due to JS Single Point of Origin limitations), AJAX'ing the character sheet and the items seemed to work fine during my limited testing (unpolished screenshot here).
What LANGUAGE this will be in (and I could be wrong) is definitely not the most difficult issue with this project. I mean really, most languages have frameworks available for doing exactly what we need. I think the choice of Python revolves around the fact that it's very powerful when paired with Django and it's fairly easy to learn.
This can definitely be done in Python, though that may mean learning a new language for some.
One thing I would very much like to see in a damage calculator (whether that's this one or one of the spreadsheets) is an estimate of the variability of your damage as well as simply your mean DPS. It's trivially true that your DPS will be affected by RNG variation: crit streaks, misses and the like. There have also been anecdotal reports of how much this affects one spec relative to another, but very little actual calculation to date. Is it possible to get some harder figures on this?
An estimate of the variation would be useful. If (say) next-gen Brutallus requires an average 4000 DPS, you may want to choose a spec that does 4100 +/- 100 DPS in place of a spec that does 4200 +/- 500 DPS. Reliable high DPS can be better than unreliable excellent DPS. Of course, many imponderables feed into DPS variation from day to day, however it should in principle be possible to give an indication of whether a spec is particularly susceptible to RNG-induced screwups. Whether you can do that by calculation or whether you have to use simulation is another matter.
I agree that there would be value in such a thing, and, even if one isn't actually going to report variability on damage, I think there's value in keeping track of how much there is, as it's going to be highly relevant for Mutilate with it's fairly randomized cycles. However, I'm thinking that might be a bit ambitious for the first release - there's actually a *lot* of cool stuff that I'd like to see done in this format, so the question is not so much what we should ideally do as what we should do first.
Just wondering...
is there any reason, why the threads "DPS Spreadsheet" and "PvE DPS / WotLK Discussion " get locked (yes I have read the sticky), while two other threads "The Roguecraft Spreadsheet" & "RogueCalc" don't get locked?
As I was not the one who locked them, I can't give you exact reasoning, but I think the logic goes like this:
The PvE/WotLK thread is too general - this is the exact sort of thread that we are not hoping to avoid - the closest thing that still exists is the Simple Questions thread, which should deal with a lot of the simpler discussion had in that thread. The more sophisticated discussions - when people have something of substance to say about them - will get their own threads.
RogueCalc and the Roguecraft spreadsheet, on the other hand, are dealing with fairly specific topics - discussion of the tool in question. These are the sort of threads that we'd like to encourage - not general discussion threads, but threads addressing one specific topic. Hence, they stayed open.
Now, the Rogue DPS sheet is more in line with this second category, but a) that thread had been getting very little action recently, and b) it's always tended to have a lot more random side-discussion in it than the other spreadsheet threads, so I can see why it was closed. If people think there's a serious need to have that thread, we can think about reopening it; but I'd just as soon see a new thread started to discuss issues specific to that spreadsheet to help move it away from the general fluff that it has tended to accumulate.
I'd also note that this probably would have been better asked in the Simple Questions thread, as it doesn't really have much to do with RogueCalc in particular.
I'd also note that this probably would have been better asked in the Simple Questions thread, as it doesn't really have much to do with RogueCalc in particular.
Thanks a lot for your answer and indeed I apologize for picking the wrong thread.
I've never used python before and have no programming experience. Any help? I entered my character name and realm in but it's still having trouble finding the information from armory.
Well, as mentioned, this basically won't work right now no matter what you do, since it hasn't been updated for 3.0. That's certainly something we plan to do, but it hasn't happened yet. It will probably be a few weeks or months before there is something usable again.
To those of you who have expressed interest in helping: sorry for the delay in getting the second round of communication out. I was hoping to get it out last week before the expansion came out, but I ran out of time; and now, of course, like most of you, I'm busy playing the game rather than theorycrafting it. Once the initial rush dies off I'll get back to coordinating development of RogueCalc.
Just revisiting this thread after a break from WoW - have you heard of the new Google product called AppEngine? Its runtime is Python-based with some exclusions, mainly file I/O, but the storage and caching features are very easy to work with. It also integrates with Django nicely and can use the templating system for easy dynamic page creation.
As far as the config files, it would be easy to store them in the DataStore, keyed by realm/player name, and load via cookies upon return.
Best of all, it's free, and you can use a '.appspot.com' domain, so there's no need to register a domain and go through the hassle of setting up DNS. Adding developers to a project is easy, and there's very detailed logging features available.
I've done a lot of work with AppEngine over the last few months, both client- and server-side, so if you're interested in exploring this path more when you pick the project back up, PM me for sure!
Nice Aldriana!. I know you are working a lot lately but I would like to ask you if in the future this could work for the Latin American servers too.
Thank you in advance.
You might want to take a look at Adobe Air, it's just awesome.
If you do look at AIR and (since it *is* awesome) decide to use it, I could help with the development. I work at Adobe on a closely-related project so I have some experience with the framework.
No, I don't have anything yet. Yes, I'm still planning to. To put it succinctly: RL circumstances of late have precluded working on and/or coordinating this for the past few weeks, and will continue to due so for some indeterminate amount of time. When I have the time and inclination to work on it, I will. Until then, it's going to remain in limbo, for which I apologize.
Edit: In the meantime, why not brainstorm a little on how we'd like to set up the 'Character" object?
What attributes, properties, etc. should be included? Do we want to include things that are not necessarily Rogue specific (I.E. pet spell damage bonus, block value) for further potential expandability?
I've just been toying around with Django, and am throwing together a talent calculator, to get familiar with the framework, and came upon these problems.
Edit2: I've done some preliminary work on a "Player" or "Character" class, really just a listing of attributes and subclasses as laid out in the "character-sheet.xsl" file at wowarmory.com
It's a LOT of things, so brace yourself, and I don't know if they're all worth keeping for just a Rogue, but here it is: http://fantumguild.net/Player.obj
A fairly simple layout, each sub-attribute is indented inwards, capitalized words are classes. I also have not yet finished the talent tree attributes, subtlety and combat need to be done.
Thoughts?
Edit3: :-( what happened to the dozen or so people offering to help? I was hoping to be able to give something to Aldriana to work with once he's ready to continue development, but I don't want it to just be my ramblings. I could use a sanity check, at the very least!
As much as I don't want to double-post, my previous post is getting a little long-toothed, and considering I'm about to throw up a bit of code, I thought I'd start a new post. Sorry :-D
So I spent some time ironing out a method for persisting talent specs, and came up with the following model (~60 lines):
from django.db import models
class TalentClass(models.Model):
characterClass = models.CharField(max_length=20, db_column='class_name')
talentClassId = models.AutoField(primary_key=True, db_column='talent_class_id')
def __unicode__(self):
return self.characterClass
class Meta:
db_table = 'talent_class'
class TalentTree(models.Model):
name = models.CharField(max_length=25, db_column='name')
talentClass = models.ForeignKey(TalentClass, db_column='talent_class_id')
TalentTreeId = models.AutoField(primary_key=True, db_column='talent_tree_id')
def __unicode__(self):
return self.name
class Meta:
db_table = 'talent_tree'
class TalentConfig(models.Model):
name = models.CharField(max_length=200, db_column = 'name')
talentGroup = models.ForeignKey(TalentClass, db_column = 'talent_class_id')
talentConfigId = models.AutoField(primary_key=True, db_column='talent_config_id')
def __unicode__(self):
return self.name
class Meta:
db_table = 'talent_config'
class TalentLov(models.Model):
name = models.CharField(max_length=200, db_column = 'name')
tier = models.PositiveSmallIntegerField('Tier', db_column = 'tier')
talentTree = models.ForeignKey(TalentTree, db_column = 'talent_tree_id')
talentLovId = models.AutoField(primary_key=True, db_column='talent_id')
def __unicode__(self):
return self.name
class Meta:
db_table = 'talent_lov'
class Talent(models.Model):
ranks = models.PositiveSmallIntegerField('Ranks', db_column='ranks')
talentConfig = models.ForeignKey(TalentConfig, db_column='talent_config_id')
talentLov = models.ForeignKey(TalentLov, db_column='talent_id')
def __unicode__(self):
return (self.talentLov.name + ": " + str(self.ranks))
class Meta:
db_table = 'talent'
It's a bit intense, but it will end up allowing a person to make checks against different talent ranks of different specs. It also tries to avoid any many-to-many relationships (which are bad DB design, typically). There may be a way to get rid of the talent_class table, or there may be a better name for the table itself (maybe "class_lov"), but I believe this works.
Django takes care of all the data management, but as an example, if you WERE to write a SQL query trying to pull up the ranks of a given talent that lies within a talent spec you've thrown together, it would look something like this (my SQL is weak, forgive me):
SELECT rank FROM talent WHERE talent_id IN (select talent_id FROM talent_lov WHERE name='Malice') AND talent_config_id IN (SELECT talent_config_id FROM talent_config WHERE name='PvEMutilate')
There's more work to be done, for sure, and I don't even know if what I just posted actually makes any sense (I think it does, but I may be getting too involved with my thought processes), so pick as many nits as you can!
A few things leap out at me - firstly, there's some stuff that's simply unnecessary for a rogue-dps-only model (just about everything under Defenses, and just about everything other than CritChance under Spell), and some more stuff that's unnecessary for any model, regardless of class or role (if you ever need to know what faction a player is, it can be worked out where necessary from race, rather than storing it explicitly, i don't think battlegroup is ever necessary to know, even for armory lookups and suchlike, etc). Stuff like Arena team ranking can probably be dropped entirely, unless you want to start conditionally recommending pvp gear as possible upgrades based on a player's ranking or something.
There's also some slight oddities stemming from the fact that it's replicating the in-game character sheet - things like ArPen being hidden away under HitRating, for example.
You DO know that poisons operate under spell mechanics?
Spell hit is derived from the same hit rating as melee hit so only one data point is need to cover both hit %'s. Spell penetration is irrelevent, bosses rarely if ever have mitigatable resistances and rogues rarely if ever have spell penetration on their gear. Spell haste is irrelevent for obvious reasons. So the only stat of significance for spells that is different from melee stats is spell crit.
Spell hit is derived from the same hit rating as melee hit so only one data point is need to cover both hit %'s. Spell penetration is irrelevent, bosses rarely if ever have mitigatable resistances and rogues rarely if ever have spell penetration on their gear. Spell haste is irrelevent for obvious reasons. So the only stat of significance for spells that is different from melee stats is spell crit.
Hit rating converts to melee and spell hit at different rates.
I'm just a code monkey, I don't exactly know which stats to keep and which stats to throw out, at least not as well as some of the more TC oriented people here, so I figured I'd throw everything in and then take stuff out if there was a problem.
That being said, a corollary to this discussion is the distinction between what I'd call "primary" and "derived" statistics, and how each should be handled. A primary statistic is something like Agility, Stamina, hit rating, crit rating, armor pen, etc. These are values that are directly allocated to the player via stats on gear, talents, or buffs. Derived, or secondary statistics, are things such as HP, armor, hit percentage, etc. Many of these secondary statistics are given by the armory tool upon query, precalculated. The question becomes, should the DPS calculator take these numbers at face value, and assume they're accurate, or should the calculator figure these numbers out itself?
Personally, I think it should calculate them, but that's just me.
And on another note, I am secretly hoping that one day, like 2020 or something, that this could be used by more than just rogues, and that's why I'd include all the extra crap like block value. But if that's just blasphemy, I suppose some day we could go back and add those things in later. :-)
Hit rating converts to melee and spell hit at different rates.
And you were thinking the coders would forget this commonly known fact and calculate melee and spell hit %'s with the same coversion from the orginal rating? Once you have the total hit rating that's all the information needed to determine both percentages.
11/05/08, 4:48 PM
