Theck's MATLAB thread - Cataclysm/4.x

Chicken wrote:

Marblehead wrote:Shouldn't there be a hit modifier for these calculations? If Censure behaves like HV, then each tick can miss/parry/dodge.

Actually to match live behavior each application would need to check for a failure to connect (Which I'd assume is part of the Seal of Truth part of the model), but the ticks themselves are guaranteed to hit. On live the ticks can suffer from partial resists, though I understand they're removing those in Cataclysm.

Exactly. The application (i.e. stack) of HV can be avoided. The ticks cannot. Of course, whether this behavior carries over to SoT needs to be tested.

I think I left the mdf.mehit factor out because the hit value depended on the proc trigger. IIRC, SoV procs can't miss, but obviously the swing that procs them can. But that means that you have a different miss rate on an auto-attack than you would on a Judgement, for example, because Judgement can't be dodged or parried.

We have to see if this behavior remains with SoT in Cataclysm. I've heard that at the moment, seals only proc off of auto-attacks, but that seems unlikely to be the final implementation.

Seals are currently only proccing off of auto-attacks. However, I wouldn't doubt if this is an intended change that sticks. Blizzard has already commented that seals are accounting for way too much of a Paladin's damage and restricting them to auto-attacks would go a long way towards reducing it.

theckhd wrote:

Chicken wrote:

Marblehead wrote:Shouldn't there be a hit modifier for these calculations? If Censure behaves like HV, then each tick can miss/parry/dodge.

Actually to match live behavior each application would need to check for a failure to connect (Which I'd assume is part of the Seal of Truth part of the model), but the ticks themselves are guaranteed to hit. On live the ticks can suffer from partial resists, though I understand they're removing those in Cataclysm.

Exactly. The application (i.e. stack) of HV can be avoided. The ticks cannot. Of course, whether this behavior carries over to SoT needs to be tested.

You're both correct. I mixed up the applications with the ticks. My bad.

theckhd wrote:I think I left the mdf.mehit factor out because the hit value depended on the proc trigger. IIRC, SoV procs can't miss, but obviously the swing that procs them can. But that means that you have a different miss rate on an auto-attack than you would on a Judgement, for example, because Judgement can't be dodged or parried.

We have to see if this behavior remains with SoT in Cataclysm. I've heard that at the moment, seals only proc off of auto-attacks, but that seems unlikely to be the final implementation.

At the moment, in beta, Censure applications are procced only from auto-attacks, but SoT damage procs can occur from any single-target attack, including HoR. However, i understand the reason why you left it out.

Once we know the exact mechanics, we can implement stuff like "dmg.SoTmelee" and "dmg.SoTranged" to cover both possibilities.

Concern about r42's gear module:

tlitp wrote:%% Enchant section - to be written.
%Enchants work exactly the same way that items do. There is an idb
%structure that contains all of the relevant enchants, according to the
%spell_id value. Since it has the same form, we can use the same equip()
%function.

% /tlitp : USE SPELL_ID HERE, NOT ITEM_ID !!1

Is this safe? The item ID and spell ID systems seem to be independent. For example:

Spell 34009 - Enchant Shield - Major Stamina
Item 34009 - Hammer of Jugement

By using spell ID, we risk accidentally overwriting an item's stats with an enchant defined later on. This is why I wrote the module to use the closest relevant item ID rather than the spell ID (i.e. "Scroll of X").

If we're going to insist on using spell IDs, we should just make enchants their own separate structure and write a short enchant() function that mimics the equip() function.

WotLK : roughly 16500 IID entries (~35500 to ~52000).
Cata : a predicted maximum of 20k entries (although it should be quite lower, in the absence of the obnoxious A/H double entries); for reference, in b12694 size(IID)<63000.

The interesting SID entries start at ~74000.

That still runs the risk of running into collisions. Older enchants will have lower SIDs, which could conflict with Cata gear.

I mean, we can run with this setup for now, but it's not actually that much extra work to create an "edb" for enchants and copy/paste the equip() function and rename it enchant().

What about head and shoulder enchants? Are you going to use their spell id too?

If not, then wouldn't it be more effective to use the item id of the respective scrolls for all the enchants to have a consistent db? There's also a special category in wowhead for that: Items > Consumables > Item Enchantments (Permanent)

If yes, then it's better to use theck's method of different dbs and functions. Risking collisions, even if it's only theoretically, it's the definition of bad programming.

An advantage that using Spell ID's for enchants has is that it makes imports from external sources easier though. The armory for instance provides you with an Item ID, but it also provides a Spell ID for which enchant the items have; linking that instead to the item ID that casts the enchant would require some coding being added to link that information together.

That only matters if you want to be able to import character data for simulations from an external source like the armory though. If it's just for building a character within the model itself using the item IDs of items that cast enchants works for the most part; the largest issue would be most of the profession specific enchants (Ring enchants, Engineering tinkers, etc.) at that point, as they only have a spell ID.

In the first version, I was using scroll IIDs. I like the idea of using SIDs better, but again, I'm just concerned that down the road we're going to run into a conflict and not notice because the gear DB will contain a lot of items at that point.

Making a separate structure for them is easy enough, and really won't take much extra coding. I'll handle coding that later this week when I have time to sit down and review the code.

Yeah, yeah, let's bury the Rogue under the burden of innumerable ceterum censeo Carthaginem esse delendam cries.

Chicken wrote:That only matters if you want to be able to import character data for simulations from an external source like the armory though. If it's just for building a character within the model itself using the item IDs of items that cast enchants works for the most part; the largest issue would be most of the profession specific enchants (Ring enchants, Engineering tinkers, etc.) at that point, as they only have a spell ID.

Is there interest in some sort of importer? I started putting together a web-based import to generate a gear_db type file that I could make accessible and/or available if people wanted.

You're thinking of getting XML data ? It'd be a rather neat addition. Do provide a sketch, so that we'll have a basic idea of how to redesign player_model and gear_db. With that in mind, I'll postpone fixing the SID issues for now.

Gaffer wrote:

Chicken wrote:That only matters if you want to be able to import character data for simulations from an external source like the armory though. If it's just for building a character within the model itself using the item IDs of items that cast enchants works for the most part; the largest issue would be most of the profession specific enchants (Ring enchants, Engineering tinkers, etc.) at that point, as they only have a spell ID.

Is there interest in some sort of importer? I started putting together a web-based import to generate a gear_db type file that I could make accessible and/or available if people wanted.

I have no idea, it was just an idea that came to mind. Being able to import item data from an external gear database would seem like it'd be very handy at the very least (Since that saves a lot of work each patch), but I'm just some random guy commenting on this.

tlitp wrote:Yeah, yeah, let's bury the Rogue under the burden of innumerable ceterum censeo Carthaginem esse delendam cries.

I'm going to need to learn Latin just so I don't have to google every time you post.

Gaffer wrote:Is there interest in some sort of importer? I started putting together a web-based import to generate a gear_db type file that I could make accessible and/or available if people wanted.

Automatically generating the gear_db file would be cool, but would probably result in a bunch of wasted memory. Storing a bunch of Leather, Cloth, and Mail gear we don't care about, for example. It may still be of some use though.

Importing a character's information would definitely be useful. All you'd need to do is come up with a list of the IID and enchant SID for each slot. You could include talents too, though that may be a little trickier on our end since I'm not sure what format it's in.

If you can turn the list of IID's and SID's into a data structure in MATLAB or a structure I can import into MATLAB, then the rest is just a bunch of equip() calls.