Theck's MATLAB thread - Cataclysm/4.x

[theckhd]

If you'd like to mess around with the code yourself, you'll either need MATLAB or a variant thereof. MATLAB is stupidly expensive itself, but there are free alternatives, including FreeMat, Octave, and Scilab. I haven't tested any of the code in these programs, but I haven't used any fancy functions or anything, so they should natively be able to run the m-files. If you run into errors, let me know and I'll see if there's anything simple I can do to help make the code more compatible with the free versions.

The files themselves are hosted on Google Code this time around to make collaboration easier. You can read and review all of the code directly through the Google Code interface, including color-coded diffs. If you want to grab the latest code, you can do so over http or with any SVN client. It's immensely easier to work with than the old system, which was me having a local copy and re-coding all the suggested changes myself.

The project name is matlabadin. Here's a bunch of useful links:

Project home page
Direct link to the trunk.
Revision hisotry
Changelog, from which you can click on any revision to see files changed, get diffs, etc.
Issue tracker
Wiki - completely empty at this point, but will (hopefully) eventually contain a page for each file describing what it does, how it works, etc.
RSS Feeds for all sorts of changes, including one that tracks every SVN commit.

The easiest way to get the whole batch is through SVN, however I hope to set up a nightly .zip repository down the line once the code has stabilized. Please contact me via PM or through the Google Code system if you'd like to help contribute to the code base in any way, even if it's just helping to keep the wiki up to date (or at this point, building it from scratch).

I hope to add a "user's guide" of sorts when I find some time, but it may be a while.

[theckhd]

See the Call to Arms thread.

[theckhd]

As of today, I'm opening this thread for discussion. Tlitp and I have been working hard on the code to get the basic framework in place. Things like, "how do we represent/store this information" are mostly taken care of, and the code is surprisingly readable.

Here's where the community comes in. I need volunteers willing to help flesh out the code base and get it up and running. There are a number of ways that you, the dedicated forum poster, can contribute. For example:

1. Code Monkey - someone with a basic knowledge of MATLAB who's interested/willing to help maintain the code base. Stuff like making minor corrections to different modules or writing calculation files. Prerequisites would be that you know enough not to screw up the code, and have a passing familiarity with how to do SVN checkouts/commits or are willing to learn how to do so. The project is hosted on Google Code: Project matlabadin.
2. Error checkers - People who will look through the code and try and spot mistakes. Things like, "You missed the Seals of the Pure modifier for Seal of Awesomeness" or "I ran the code in Octave and got an error on line x of module y, here's how I fixed it." If you don't want to mess around with SVN commits but can read MATLAB code, this could be the job for you!
3. Wikinators - Eventually I want the wiki to include a page for each module describing what it does and how it's used. At this point, I don't have a specific idea how I want to do this, and won't have time to work on it until much farther down the line. If someone else wanted to make this their pet project, it would be an immense help.
4. Data Miner - Willing to do simple fetch/retrieve operations. Things like "Here's a list of all of the spell coefficients and base damages for our abilities at level 85, according to wowhead." Beta access isn't even necessary for this. If you're able to read MATLAB code and willing to check these sorts of things against the code and post about possible errors, that's even better.
5. Tester - I'll need people to go in and test things in the Beta from time to time. Things like "Does Talent X affects the damage of Ability Y or not" or "What's the proc rate on Talent Z?" This would probably require beta access.

How to contribute

1. If you are interested in helping and need project access on Google Code: Send me a PM with your Google Account e-mail address and the type of work you'd like to help out with. You can contact me either on the boards here or via [email protected] . You need a Google Account to gain access to the project. If you contact me via e-mail, please mention your forum name so I have some clue who I'm talking to.
2. If you are interested in helping with the code but do not need project access: Simply do whatever it is you're willing to do to help, and post your findings, observations, comments, or whatever in this thread. Also, keep an eye on this thread, as tlitp and I will periodically be posting requests when we need things checked or tested. I will try and keep a "master list" of unresolved issues/requests in the post above this one.

Feel free to post questions about the code as well. If you're trying to help but don't understand what a certain line of code (or even an entire module) is doing, ask! Chances are one of us will have a good answer, but who knows - you might catch us making a bad assumption or doing something in a more complicated fashion than is necessary.

[Gaffer]

1) Does Seals of the Pure affect Censure?

Tested while completely naked at a level 70 training dummy. I combat logged, started a 90s timer when I hit my five stack, and ended logging when the timer stopped. After filtering all non-Censure lines out and including only five stacks while ignoring crits, it's apparent that Seals of the Pure affects Censure.

With Protection Specialization selected, Censure ticked 30 times (minus one crit) for 82 damage each time. With Protection Specialization selected and only 3/3 Seals of the Pure, Censure ticked 30 times (minus one crit) for 94 or 95 damage. 82 * 1.15 = 94.3.

[tlitp]

Please test Cens' haste scaling with :
- SwiftRet* alone (i.e. no other haste source, including HR from gear)
- SwiftRet+WoA, without other sources of haste

* or an analog (WF/IIT)

[Gaffer]

Tested in the same way I did for the SotP damage.

Base numbers with only Protection Specialization selected:

$time_diffs = array(3.015, 2.999, 3.24, 2.814, 2.999, 2.927, 2.982, 3.066, 3.015, 2.982, 3.016, 3, 3.015, 3.021, 2.967, 3.032, 2.916, 3.044, 2.972, 3.058, 3.289, 2.715, 3.327, 2.666, 2.966, 3.015, 3.399, 2.599, 3);

Average: 3.0019310344828

Retribution Specialization with 21 points filled to grab Sanctified Retribution:

$time_diffs = array(3.049, 2.999, 3.015, 2.999, 3.005, 2.944, 3.032, 2.999, 3.065, 2.966, 3, 2.916, 3.065, 2.999, 3.032, 2.966, 2.95, 3.065, 2.999, 2.999, 3.249, 2.699, 3.049, 3.001, 2.997, 2.933, 3.065, 3, 2.999);

Average: 3.0019310344828

Same as above with Wrath of Air totem:

$time_diffs = array(2.899, 2.849, 2.85, 2.865, 2.866, 2.849, 3.115, 2.516, 2.9, 2.799, 2.965, 2.849, 2.866, 2.849, 2.849, 3.116, 2.916, 2.499, 2.899, 2.865, 2.766, 2.95, 2.849, 3.165, 2.899, 2.416, 2.949, 2.833, 2.882, 2.849, 2.866);

Average: 2.8582258064516

[Marblehead]

During a fast reading through the code, I noticed something.

equip.m

Code: Select all

gi=length(idb);
while gi>0 && not(strcmp(idb(gi).name,iref))
    gi=gi+1;
end

I think it should be gi = gi - 1, since gi starts as idb's lenght and if it increases, it will never reach the conditions to stop the loop.

[tlitp]

@ Gaffer : thanks. Censure seems to be rather odd at this moment (scales with spell haste when both prot/ret use mainly physical haste; uses physical crit table, but has the spell-specific base multiplier). We'll just have to wait and see its final implementation.
@ Marblehead : thanks. Fixed and upped the commit.

[Gaffer]

Yeah, I thought that was odd. I even tested with the Shaman dropping Windfury just to make sure it wasn't Sanctified Retribution not applying to the caster, but got the same results.

[Marblehead]

stat_model.m

Code: Select all

mod.AotL=6.*talent.ArbiteroftheLight;

mod.AotL=0.06.*talent.ArbiteroftheLight;

Code: Select all

player.str=floor(floor((base.str+gear.str+extra.str)).*mod.BoK);
player.sta=floor(floor((base.sta+gear.sta+extra.sta).*(1+mod.TbtL)).*mod.BoK);
player.agi=floor((base.agi+gear.agi+extra.agi).*mod.BoK);
player.int=floor((base.int+gear.int+extra.int).*mod.BoK);

player.str=floor(base.str.*mod.BoK)+floor((gear.str+mod.SoE+cons.str+extra.str).*mod.BoK);
player.sta=floor((base.sta+mining).*(1+mod.TbtL).*mod.BoK)+floor((gear.sta+mod.PWF+cons.sta+extra.sta).*(1+mod.TbtL).*mod.BoK);
player.agi=floor(base.agi.*mod.BoK)+floor((gear.agi+mod.SoE+cons.agi+extra.agi).*mod.BoK);
player.int=floor(base.int.*mod.BoK)+floor((gear.int+cons.int+extra.int).*mod.BoK);

cons is a struct for consumables (food/elixirs/flask). I understand that it will be implemented later on all the stat calculations, but I used it to give the correct formulae.

Code: Select all

player.armorystr=floor(floor((base.str+gear.str)));

Is there any point for double floor()? Actually, what is the purpose of this line?

Code: Select all

player.hitpoints=base.health+10.*(player.sta-10)+gear.health;

player.hitpoints=base.health+10.*(player.sta-18)+gear.health;

Also, we'll have to check and add tauren's racial at some point.

Code: Select all

%melee abilities ("physical crit")
player.phcrit=base.phcrit + ...                     %base physical crit
    player.agi./cnv.agi_phcrit + ...                %AGI
    (gear.crit+extra.crit)./cnv.crit_phcrit + ...   %crit rating
    -npc.phcritsupp;                                %crit suppression

%spell abilities ("spell crit")
player.spcrit=base.spcrit + ...                     %base spell crit
    player.int./cnv.int_spcrit + ...                %INT
    (gear.crit+extra.crit)./cnv.crit_spcrit + ...   %crit rating
    -npc.spcritsupp;                                %crit suppression

%regular melee attacks (one-roll system)
%this gets modified again after boss stats to enforce crit cap
player.aacrit=base.phcrit + ...                     %base physical crit
    player.agi./cnv.agi_phcrit + ...                %AGI
    (gear.crit+extra.crit)./cnv.crit_phcrit + ...   %crit rating
    -npc.phcritsupp;                                %crit suppression

In all 3 of them:

+mod.LotP+skinning-npc.phcritsupp;

Also, consumables are missing like everywhere else.



gear_db.m

Code: Select all

%% Cloak
idb(39001).name='Enchant Cloak - Mighty Armor';
idb(39001).barmor=225;

If I'm not mistaken, armor enchants are earmor, not barmor.

[tlitp]

@ Marblehead :

1. not an issue
2. consumables/buff_model is a mix of WIP/NYI, don't worry about it for now; as for the dependency issues - hm, that's actually a good question
3. introduced in r15 by Theck, it was probably an attempt to use an entity that is directly available to a player (character panel on armory profile); double floor() is redundant, of course
4. fixed; tauren is NYI, player_model will have to be rechecked anyway (later beta builds)
5. standard professions are now handled by PM+SM; LotP is fixed
6. probably an oversight; cloak slot does grant base armor, but any +armor enchant counts as extra armor

Testing dependencies on b12644
- check the total stamina without gear/talent points (/spec)
- equip a stamina-heavy gear set, check the total stamina (still untalented)
- eat something (keep in mind the stamina bonus it grants), throw a BoK, check the total stamina (again, untalented)

[Gaffer]

Tested on my level 83 Dwarf Paladin
Naked, no spec: 152
Stamina Set, no spec: 3969
Stamina Set, no spec, food buff, BoK: 4209

[theckhd]

mod.AotL gets wrapped directly into a crit percentage, and doesn't show up anywhere else. If I defined it as 0.06, then I'd need to multiply it by 100 later in the one place I used it. Makes more sense to just define it as 6.

player.armorystr should spit out the STR value that you read off of your character sheet on the armory. I started using armory strength as the plot axis for the TPS Stat calculation files, because I wanted something that was easier and more universal than fully raid-buffed STR. It's a lot easier to just check your armory and see what it says your STR is than it is to round up some friends to buff you.

Since I plan on using it again, I just integrated it into the player structure in stat_model. The reasoning behind the double floors is ... well, there isn't any. I copy/pasted the player.str line, deleted the arguments that didn't go into armory strength, and changed the field name. I just forgot to get rid of the redundant floor.

Similarly with the cloak enchant - I was rushing to get the slots all implemented and typed the wrong thing without thinking. That's exactly why I asked for help looking over the code. Who knows how long that would have gone unnoticed if it was just tlitp and I working on the project!

Seperate topic: I just noticed that I've accidentally replaced the inherent mod() and dot() functions with structures. I've already renamed the dot structure, and I'm thinking we should probably rename the mod structure as well, despite the fact that I really like the name mod. I can't decide between "mdf" and "mo" but I'm leaning towards the latter. Any opinions on that?

[Marblehead]

Stat dependency testing

I'll name the following sets of formulae "Expected_1" and "Expected_2" respectively:

Expected_1:

Code: Select all

player.str=floor((base.str+gear.str+cons.str).*mod.BoK);
player.sta=floor(floor((base.sta+gear.sta+cons.sta).*(1+mod.TbtL)).*mod.BoK);

Expected_2:

Code: Select all

player.str=floor(base.str.*mod.BoK)+floor((gear.str+cons.str).*mod.BoK);
player.sta=floor(base.sta.*(1+mod.TbtL).*mod.BoK)+floor((gear.sta+cons.sta).*(1+mod.TbtL).*mod.BoK);

(I omitted mod.mining, mod.SoE, mod.PWF and extra in this test. That causes player.agi and player.int to have the same formula as player.str, thus they're not included)

Specimen: Level 83 Paladin

Tests: 1) naked, 2) heavy-stamina gear, 3) heavy-stamina gear plus consumables (+40 str/+40 sta food)

Variations for every test: a) untalented, b) untalented w/ BoK, c) talented (TbtL), d) talented /w BoK


1. Naked

a. untalented

Code: Select all

Strength   164
Stamina    152

b. untalented /w BoK

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  |  172 |     172    |     172    |
Stamina   |  159 |     159    |     159    |

OK

c. talented

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  |  164 |     164    |     164    |
Stamina   |  174 |     174    |     174    |

OK

d. talented /w BoK

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  |  172 |     172    |     172    |
Stamina   |  183 |     182    |     183    |

Expected_1 is off. This is caused by flooring after multiplying with mod.TbtL, before multiplying with mod.BoK. However, if we don't floor after multiplying with mod.TbtL, we'll get wrong values later on.


2. Heavy-Stamina Gear

a. untalented

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1637 |    1637    |    1637    |
Stamina   | 3450 |    3450    |    3450    |

OK

b. untalented /w BoK

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1718 |    1718    |    1718    |
Stamina   | 3622 |    3622    |    3621    |

Expected_2 is off. This is caused by flooring before adding.

c. talented

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1637 |    1637    |    1637    |
Stamina   | 3966 |    3967    |    3966    |

Expected_1 is off. This is caused by adding before flooring.

d. talented /w BoK

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1718 |    1718    |    1718    |
Stamina   | 4165 |    4165    |    4165    |

OK


3. Heave-Stamina Gear + Consumables

a. untalented

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1677 |    1677    |    1677    |
Stamina   | 3490 |    3490    |    3490    |

OK

b. untalented /w BoK

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1760 |    1760    |    1760    |
Stamina   | 3664 |    3664    |    3663    |

Expected_2 is off. This is caused by flooring before adding.

c. talented

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1677 |    1677    |    1677    |
Stamina   | 4012 |    4013    |    4012    |

Expected_1 is off. This is caused by adding before flooring.

d. talented /w BoK

Code: Select all

          | Real | Expected_1 | Expected_2 |
----------|------|------------|------------|-
Strength  | 1760 |    1760    |    1760    |
Stamina   | 4213 |    4213    |    4213    |

OK


So, both sets are wrong. They must actually be a little bit more complicate that we thought.

[theckhd]

Could you give us the gear.str and gear.sta values for the different configurations so I can double-check this and mess around with possible solutions?
<edit> Nevermind, I can calculate them myself from the untalented & unbuffed configuration. BRB, need more coffee.

Also, did you try round() instead of floor() at all?