Detailed EP

[dazer]

I'm requesting pull so you see how this is going. If you want to pull the package changes before this I can easily issue new commits/request.

Each section manages its calculations differently; I'm going to explain them a bit so you can review them comfortably:

• Glyphs: setting them to True/False works here. It can take a list of glyphs or default to check them all. Note that this method returns dps values, not ep.
• Procs: the process involves deleting/creating procs objects (well, I think delattr simply destroys the reference). I implemented an escape except just like I previously did with talents.
• Gear buffs: setting them to True/False does the trick here too. These two (procs and gear buffs) share the same method and it will not default: you need to feed it a list of procs/buffs; the method distinguishes them just fine (as long as they don't share a name, which is always true as of now)
• Weapon dps: this computes de EP for 1dps difference. It works just like the method for basic stats: add and substract 1.0
• Weapon enchants: this one was tricky. It doesn't make much sense to append a new proc to the weapon, so what it compares to get EP is the unenchanted dps (for each weapon) with the enchanted one for every melee enchant. It creates/deletes enchants to do so with a little difference: it deletes the previous enchant before setting a new one. Given that there are very few melee enchants it always returns values for both.
• Weapon speed: the concept of taking out a speed doesn't hold here (a weapon always has some speed), and neither does giving EP for 0.1 speed difference. I'm taking Aldriana's advice and forcing a list of speeds to be passed to the method. As per how the former 3.x spreadsheets worked, I'm not giving the abs() value but rather let it stick with the sign: this, I think, will help taking decisions if the former speed was not the optimal one (1.8/1.8 for instance) or if we ever reach (through nerfs/buffs or gear if that's possible) the break point at which main gauche takes over poison damage.

I tried to build them avoiding nasty code at all costs and I think it is very compact but readable now; I don't know if the methods I set in place to create/delete objects or nested getattr are what they should look like though.

Only assassination.py computes those in my commit. It'd be great if you told me what should go in and what not; glyphs, for instance, is not very usefull for us: I put it there so you can see it in action, but it probably will not make it to the final cut (I mean the usage, the method looks fine to me).

[dazer]

I let go of del/set glyph as well as del_proc. However, the other set methods (set_enchant and set_proc) would require to build a proc/enchant object calcs side, which I find odd. I could easily deprecate del_enchant but I think it helps readability getting rid of a couple 'for' loops.

[dazer]

Naming the procs list to be analyzed as 'procs' was a bad idea; it kept me from fully understanding what julienp was trying to adress.

On the set/del methods, I feel content with the three remaining, but if someone thinks they should go I'll happily refactor them.

edited the 'op' to better reflect the changes made.

[Aldriana]

Is this ready to be pulled, or does it still need work?

[dazer]

The methods are ready, but the combat/subtlety scripts are not calling them yet; assassination.py calls them all. You can either tell me what do you find usefull to be computed there or simply pull and tweak them as you see fit.

[Aldriana]

Personally I think the assassination/combat/subtlety scripts are getting a bit bloated - I'm not entirely sure to do with it, but when I'm doing heavy-duty debugging I frequently find myself commenting out significant sections of them as it is. I suppose a partial solution would be to throw some command line parsing on to the scripts and add some options for which numbers you want displayed, but realistically I think the primary use of this sort of function will be via the UI - either raconzor's test UI, or the one being built over at shadowcraft-ui.

In any event, so long as the feature is working I'm inclined to pull it - we can worry about what to do with it where later.