A Call to Arms - Cataclysm Mechanics testing

[theckhd]

From stat_model.m:

Code: Select all

mod.EfaE=0.3.*sign(talent.EyeforanEye)+0.05.*talent.EyeforanEye;

Freemat 4.0 cannot recognize the function sign().

That's an easy fix, the sign() call is just to give you a logical 0 or 1 for that slot. I could replace that with almost any other piecewise function given the right arguments.

I was able to progress to another error in stat_model.m:

Code: Select all

player.str=floor(floor((base.str+gear.str+extra.str)).*mod.BoK);

Error: Unsupported type for get(string)

On the plus side, Octave seems to work through this fine. FreeMat is just nice and visual.

That's an interesting one. It seems like FreeMat is interpreting "str" to mean string, when it's really just supposed to be a field of the player structure. I'm not sure if there's an easy fix for that other than renaming the field. I'll mess around with it when I get time this week.

[Gaffer]

FreeMat also seems to be having some big time issues with handling gear_db on my system. Running gear_db via the console takes more than 2 minutes to complete.

[Gaffer]

That's an interesting one. It seems like FreeMat is interpreting "str" to mean string, when it's really just supposed to be a field of the player structure. I'm not sure if there's an easy fix for that other than renaming the field. I'll mess around with it when I get time this week.

This looks to be specific to matlabadin. .str doesn't seem to always imply a string in FreeMat. I do not have any issues with the following:

Code: Select all

global mydb

mydb=struct('str',1,...
    'field2','Default Value',);

mydb(1).str=floor(1.001);
mydb(1).field2 = 'Random';

myvariable.str = floor(3.001);

[theckhd]

I'm looking into this at the moment.

As for the gear_db problem, it seems like FreeMat is just incredibly slow at working with large structures. At first I thought it was just a delay from initializing such a large structure, but even within one element it's incredibly slow. It takes a few seconds to process each individual line of a new item, which is ridiculous.

A little quick testing shows the culprit is capital letters. I'm not kidding. After initializing the idb structure with lines 104-129 of gear_db, the following two lines give very different results:

idb(100000).name='test'
idb(100000).name='Test'

The first is nearly instantaneous. The second takes a little over a second. However, if you run them in the reverse order, both take about the same time. I have absolutely no idea why, but it seems like FreeMat handles strings or string fields of structures in a different way if any of the strings stored in the structure contains a capital letter. I haven't been able to find any discussion about FreeMat and large structures.

I could rewrite all of gear_db to use lowercase letters only, since it's only a cosmetic thing. But it seems like an awfully stupid thing to have to do. I'm more inclined to just suggest people use Octave and ignore FreeMat if it's that bad. Or offer an alternative gear_db_freemat file for people who can't use Octave for some reason.

[Gaffer]

A little quick testing shows the culprit is capital letters. I'm not kidding.

I get the same results. Probably the most ridiculous thing I've seen in awhile.

Both are being actively developed and openly available under the same license. There isn't really a reason to introduce a ton of work-arounds to support one when the other doesn't need them. Scilab support will also be an annoyance. I attempted to run the sample calculation, but it seems that % is not used to identify comments in it. Turns out, it uses C-style comments.

[Chicken]

I don't think it'd be needed to support every single free alternative anyway, especially if they differ in such a basic aspect. Trying to support everything is just going to turn into a very big headache; better to make sure that at least one of the free alternatives to MATLAB works with your code, and to just point people to that particular free alternative if they report having issues with any of the other ones.

[theckhd]

I'm also noticing that FreeMat has trouble with the player_model file. It seems to have trouble with the fact that base is declared as a global variable and happens to be the output of the function. Removing global status and adding it as an argument to npc_model fixed it for me. I can't decide whether it's worth incorporating this into the repo version though. As far as I'm aware, there are no other functions that require base, but I'm also not convinced it's worth trying to keep compatibility with FreeMat either. This is time I could be spending doing something useful, after all.

[theckhd]

Hm.... I just noticed (because FreeMat throws a warning at me) that I've inadvertently chosen names poorly, and replaced the inherent mod() and dot() functions with my structures. I may go through and change mod.* to mdf.* just because I don't like overwriting built-in functions that could potentially be used.

[theckhd]

Bumping. See the original post for information about the "maintankadin" guild on World of Logs. All your parse are belong to us!

[Digren]

Hey Theck, this is a low-importance back-burner request, but at some point it would be useful to know. At what high ratio of parry to dodge does the diminishing returns make additional agility provide more avoidance than additional parry rating?

With agility and parry as the red gem choices, I'd like to quantify this ratio (and likely flag it as so high that we can make the blanket statement to always pick parry over agility when matching a red socket color).

[theckhd]

That will be an easy question to answer once we know what the DR curves for dodge and parry look like. tlitp has asked for some data on that topic, but so far Arcand is the only one who's given him any feedback.

[towelliee]

tester here

[Neziah]

Tester here also. I am pretty much done raiding on live so I should have more time now.
Is there anything in particular you would like to see, or just everything and anything?

[theckhd]

Nothing specific at this point, just data logging.

Though if anyone would be so kind as to help us determine ability damages, that would help. I'm trying to nail down the base damage and sp/ap scaling of each ability. I have most of them already, but more data points as confirmation would help.

I'm probably going to try and carve out a few hours this weekend to finish up the rotation simulation code, but the results it yields will only be as good as the data we give it.

[Marblehead]

Nothing specific at this point, just data logging.

Though if anyone would be so kind as to help us determine ability damages, that would help. I'm trying to nail down the base damage and sp/ap scaling of each ability. I have most of them already, but more data points as confirmation would help.

I'm probably going to try and carve out a few hours this weekend to finish up the rotation simulation code, but the results it yields will only be as good as the data we give it.

I have some parses ready for upload, but my intention was to clarify the mechanics. I didn't think that you want to check the coefficients yet, since they are likely to change at the next builds with all the finetuning, so all the parses are with the same setup. But maybe you can compare them with other people's parses anyway.

Here we go.


Profile:

Level - 85
Gear - Naked with Hand Axe and Small Shield
Spec - 0/31/10 (glyphs included)
AP - 573
SP - 196


Parses:

• Seal of Justice: It seems that SoJ's damage is on the spell attack table. It can miss and crit (no dodge or parry).
• Seal of Righteousness: SoR can't miss/crit/parry/dodge. If the swing connects, SoR will hit.
• Seal of Insight: Health and mana don't proc independently, always together.
• Seal of Truth: SoT proc doesn't happen from the very first swing since there aren't any Censure stacks. Also, it behaves exactly like SoR. Censure is apparently on the melee attack table and it can miss/dodge/parry on refresh. The ticks always do damage and can crit.
• Seal of Truth interaction with other abilities: Censure doesn't get affected (i.e. applied or refreshed) by any other ability. SoT procs can happen from CS/HotR/SotR/Judge/HoR.
• Seal of Righteousness interaction with other abilities: Same as SoT procs.
• Judgement of Truth while melee-ing (full Censure): Judgement procs SoT (as stated before).
• JoT & JoR from afar (w/o Censure): Judgement procs SoR too. It's apparently on the ranged attack table.
• JoI & JoJ from afar: Nothing special.
• Crusader Strike: Clearly on the melee attack table. Generates Holy Power even if it doesn't connect. Vindication can miss.
• Hammer of the Righteous & Shield of the Righteous: HotR functions the same as CS for its physical component on the main target, doing a small amount of damage. If it doesn't connect, the AoE doesn't go off. Its AoE component is on the spell attack table, thus it can crit and miss. SotR is on the melee attack table and when it doesn't connect, it resets Holy Power to 1. That means that missing a 1-HoPo SotR doesn't consume any Holy Power, while missing a 2-HoPo or 3 HoPo SotR, it consumes 1 and 2 Holy Power respectively.
• Avenger's Shield on 2 targets, Holy Wrath on 1/2/3/4 targets & Consecration: They're all probably on the spell attack table. Consecration can crit and miss any of the ticks.

P.S. Sorry if spammed WoL too hard. I thought it would be better to be fragmented.